Android逆向——Android逆向进阶（1）

0x00 前言

有价之宝：戳这里
无价之宝：戳这里

说明

最近同步分析ELF文件格式分析。
本文在大佬教学后进行笔记整理以及个人体会进行一个记录。

ELF文件格式分析（1）

内容

1.so文件保护学习
2.自动吐出校验码
3.栈跟踪
4.adb简单调试

0x01 so文件学习分析。

准备好我们的demo

反编译

查看lib文件夹

我们找到了一个关键的so文件。这个so文件的含义就是壳的含义。

egis.so逻辑分析。

打开ida。

这里有一个知识点。

JNI_OnLoad 的执行优先级是高于其他java输出函数。所以这里so文件就会执行这个函数，双击进行跳转。

分析

JNI_OnLoad

当Android的VM(Virtual Machine)执行到C组件(即*so档)里的System.loadLibrary()函数时，
首先会去执行C组件里的JNI_OnLoad()函数。

 EXPORT JNI_OnLoad
LOAD:00001D28 JNI_OnLoad                              ; DATA XREF: LOAD:000003B4↑o
LOAD:00001D28
LOAD:00001D28 ; FUNCTION CHUNK AT LOAD:00001818 SIZE 00000018 BYTES
LOAD:00001D28
LOAD:00001D28                 PUSH            {R4-R7,LR}
LOAD:00001D2A                 SUB             SP, SP, #0x14
LOAD:00001D2C                 STR             R1, [SP,#0xC]
LOAD:00001D2E                 STR             R0, [SP,#8]
LOAD:00001D30                 BLX             getpid
LOAD:00001D34                 LDR             R1, =(aLibegisSo_0 - 0x1D3C)
LOAD:00001D36                 LDR             R4, =(off_5F50 - 0x1D42)
LOAD:00001D38                 ADD             R1, PC  ; "libegis.so"
LOAD:00001D3A                 BL              sub_15CC

在so文件里看到一个so的文件名。

 "libegis.so"

这个就是自己本生的so名称，也就是说这里是自己调用了自己。

按f5进行查看。

发现这里进行一个调用。

进行上下文检查，发现了关键字符串

那么这个so的逻辑就是自我检测。

但是有一个问题就是这个so文件没有和java层进行交互，如果和java层不进行交互的话，那么这个so就没有意义。

但是还有一个可能就是这个so和其他的so有一定的联系。

egis_security.so分析

我们接着打开 IDA进行egis_security这个so的分析

来看一下输出表。

这里就是java层的输出函数。

名称PayegisBarcode_decode，getZbarSoVersion

这里就是说这个so很有可能就是保护另外一个so文件的检验。

总结

那么就是说 egis.so 自身保护自己。然后通过egis_security和java层进行交互，并且保护so。

相当于egis_security做了一个中间量，并且对进行交互的so进行了一个交互。egis.so 则是通过间接交互，来实现它的功能。

0x02 自动吐出校验码

demo测试

反编译 分析

if-eqz v3, :cond_2

    .line 43
    iget-object v3, p0, Lcom/droider/sn/MainActivity$1;->this$0:Lcom/droider/sn/MainActivity;

    const-string v4, "\u6ce8\u518c\u7801\u6b63\u786e"

    invoke-static {v3, v4, v5}, Landroid/widget/Toast;->makeText(Landroid/content/Context;Ljava/lang/CharSequence;I)Landroid/widget/Toast;

    move-result-object v3

    invoke-virtual {v3}, Landroid/widget/Toast;->show()V

    goto :goto_0

    .line 45
    :cond_2
    iget-object v3, p0, Lcom/droider/sn/MainActivity$1;->this$0:Lcom/droider/sn/MainActivity;

    const-string v4, "\u6ce8\u518c\u7801\u9519\u8bef"

    invoke-static {v3, v4, v5}, Landroid/widget/Toast;->makeText(Landroid/content/Context;Ljava/lang/CharSequence;I)Landroid/widget/Toast;

    move-result-object v3

    invoke-virtual {v3}, Landroid/widget/Toast;->show()V

    goto :goto_0
.end method

这里我们找到了一个相关的地方。
其实这个是重新写的，我作死，就没了。
不想啰嗦了。

向上查看。

invoke-virtual {v1, v0}, Ljava/lang/String;->equalsIgnoreCase(Ljava/lang/String;)Z

这里发现是两个寄存器的值进行比较。

v1和v0

我们继续向上看，v1存的是什么东西。

invoke-virtual {v1}, Ljava/lang/String;->length()I

我们找到这样一句话。

这句话就是说v1.length.计算字符串的大小。

为什么要计算大小呢？

if-nez v3, :cond_1

    .line 38
    :cond_0
    iget-object v3, p0, Lcom/droider/sn/MainActivity$1;->this$0:Lcom/droider/sn/MainActivity;

    const-string v4, "\u8bf7\u8f93\u5165\u7528\u6237\u540d\u4e0e\u6ce8\u518c\u7801"

    invoke-static {v3, v4, v5}, Landroid/widget/Toast;->makeText(Landroid/content/Context;Ljava/lang/CharSequence;I)Landroid/widget/Toast;

    move-result-object v3

    invoke-virtual {v3}, Landroid/widget/Toast;->show()V

下面有判断说：如果是0的话就输出请输入XXX就是没有的意思，那么我们就知道v1寄存器里存的是我们输入的东西。

相对的v0，就是和我们输入比较的东西，也就是我们要输出的寄存器。

插入代码

 invoke-static {v0}, Lcom/android/killer/Log;->LogStr(Ljava/lang/String;)V

我们输出v0寄存器里的值就可以了。

测试

0x03栈跟踪

demo 测试

反编译分析

反编译之后找到这个位置。

.method private c()V
    .locals 2

    .prologue
    .line 27
    const-string v0, "who called me?"

    const/4 v1, 0x0

    invoke-static {p0, v0, v1}, Landroid/widget/Toast;->makeText(Landroid/content/Context;Ljava/lang/CharSequence;I)Landroid/widget/Toast;

    move-result-object v0

    invoke-virtual {v0}, Landroid/widget/Toast;->show()V


    .line 29
    return-void
.end method

这个的含义就是让你去判断是谁调用了c。

那么我们就要进行一个对栈进行打印了。

堆栈打印

 new-instance v0, Ljava/lang/Exception;

    const-string v1, "HAI-------print trace"

    invoke-direct {v0, v1}, Ljava/lang/Exception;-><init>(Ljava/lang/String;)V

    invoke-virtual {v0}, Ljava/lang/Exception;->printStackTrace()V

通过这四句来对堆栈进行一个打印。

回编译测试

这里输出结果就是 c,b,a。

但是栈有一个特点就是先进后出。

所以正确的顺序就是 a,b,c

所以很明显就是 a调用b，b调用c。

0x04 DDMS方法追踪

工具说明

夜神模拟器

first adb命令

首先进行连接adb

adb connect 127.0.0.1:62001

然后使用adb shell进行检测

这样就是连接成功了。

我们使用adb进行apk的安装

打开ddms。

second ddms调试

因为虚拟机有问题，所以这里使用真机进行测试。

真机打开软件。

首先建立过滤规则。

进行简单过滤设置。

选择进程，然后点击这个按钮

点击之后，运行 软件，单击按钮。然后停止，进行抓取。

在这里我们可以清楚的看到软件的运行过程。

onclick

然后 a

然后b

然后c

0x05 结束语

收获

1.知道了一种常见的保护逻辑。
2.基本的打印输出
3.知道了如何栈跟踪
4.ddms调试详细跟踪

以上