arm系列文章

导读：

为啥要学arm汇编，因为逆向so的需要，当so被反汇编之后得到的是一堆的arm汇编代码，而不是c/c++代码，虽然有IDA的强大的F5功能，但是事实上我们没法完全去相信IDA的F5，需要结合汇编代码进行结合辅助我们进行代码分析，这也就是我们为什么要学习arm汇编的原因

ARM体系结构

RISC与CISC

ARM体系的处理器继承自RISC（精简指令集计算机），之所以采用RISC，是因为CISC（复杂指令集计算机）的指令只有大约20%会被在80%的程序设计被重复使用，而大约80%的指令只占据程序设计的20%，这种设计显然不合理。

RISC结构优先选取使用频率最高的简单指令，避免复杂指令；将指令长度固定，指令格式和寻址方式种类减少；以控制逻辑为主。

流水线技术

这里只简单介绍一下arm7的三级流水线技术，为啥？因为弟弟我的手机只有这个三级流水线的。。。

三级流水线是哪三级？

  1. 取指级
    取指级完成程序在存储器的指令读取，并将指令放入进流水线

  2. 译码级
    对指令进行译码，为下一周期准备数据路径需要的控制信号。这一级指令“占有”译码逻辑，而不“占有”数据路径。

  3. 执行级
    指令“占有”数据路径，寄存器堆栈被读取，操作数在桶形移位器中被移位，ALU产生相应的运算结果并写回到目的寄存器中，ALU结果根据指令需求更改状态寄存器的条件位。

picture 1

每一级中的硬件必须能够独立操作，而不能多级占用同一硬件资源。每级指令经由流水线的一个时钟周期完成一条指令，三级则需要三个时钟周期。

当通过R15（程序计数器，即前面提到的CPU内部的存储器用于存储指令的存储器）总是指向取指的指令，而不是指向正在执行的指令或正在译码的指令。通常，人们把正在执行的指令作为参考点，称为第一条指令，因此PC总是指向第三条指令（执行级）。

PC值的计算

对于ARM指令，PC值=当前程序位置+8；对于Thumb指令，则有PC值=当前程序执行位置+4

ARM反汇编基础

android指令支持

这里只记我平时常用的两种架构

  1. armeabi-v7a

    • Thumb-2指令集扩展： 性能堪比32位ARM指令，简洁性类似于之前16位的Thumb指令集，同时支持16位与32位指令集的混合使用。
    • VFP硬件FPU指令：包括VFPv3-D16,除了ARM核心中的16个32位寄存器，还包含16个专用的64位浮点寄存器。
      同时支持可选扩展NEON、VFPv3-D32和ThumbEE, armeabi-v7a已经被并入AArch32架构。

  2. arm64-v8a
    兼容armabi-v7a,并支持AArch64架构，VFP扩展升级为v4版本， NEON指令集扩展是必需的。
    64位arm64-v8a规格的处理器支持AArch64和AArch32两种运行模式。
    在AArch64下，所有代码数据寻址采用64位地址空间，寄存器也采用64位的。

在AArch32模式为32位，因此，在此模式下代码数据寻址和寄存器的使用与之前一样，才有32位的。

因此，arm64-v8a完全兼容armeabi-v7a。

ARM原生程序的生成过程

  1. 编写代码

  1. 编译代码
    编写完代码之后需要进行代码的编译，此处跟书本不一样，主要采用clang,此处采用官网的说明，而书中采用的是gcc
    Android NDK编译

    从 NDK r19 开始，NDK 默认安装的工具链可供使用。与任意构建系统进行交互时不再需要使用 make_standalone_toolchain.py 脚本。为了确保使用正确的架构进行构建，请在调用 Clang 时使用 -target 传递适当的目标，或调用具有目标前缀的 Clang。例如，若要为 64 位 ARM Android 编译值为 21 的 minSdkVersion，可使用以下两种方法，您可以选择使用其中最方便的方法

     $ $NDK/toolchains/llvm/prebuilt/$HOST_TAG/bin/clang++ -target aarch64-linux-android21 foo.cpp

 $ $NDK/toolchains/llvm/prebuilt/$HOST_TAG/bin/aarch64-linux-android21-clang++ foo.cpp

    picture 1

    picture 2

    如上图，执行完这一句之后sum.cpp已经被编译完成。

  2. 完成代码的预处理

    预处理阶段，编译器将代码中的预处理指令进行处理。例如#include 中包含的头文件会全部编译进来，#define预定义、#if预条件处理等也都会在这里被编译器处理。详细的输出信息通过-E进行查看。

clang++ -E -fPIE file.cpp -o file.i

相应的.i文件的内容如下，由于我包含了一个iostream，结果几行代码，预编译之后变成了将近30000行。
picture 3

  1. 编译
    该阶段会进行语法等代码规范性检查，检查无误会把代码翻译成ARM汇编代码，输出信息通过-s选项进行查看。
    clang++ file.i -S -fPIE -o file.s执行该命令后会生成file.s的汇编文件。
    picture 4

  2. 汇编
    汇编阶段主要用来将汇编文件生成目标文件。
    clang++ -c file.s -o file.o

picture 5

  1. 链接
    将所有的目标合并，生成最终的可执行程序或动态链接库。
    clang++ file.o -fPIE -o file

Arm汇编基本语法

.text

在编译后用于存放代码的代码段。位于ARM EABI的ELF中。

.rodata

用于存放数据的数据段。位于ARM EABI的ELF中。

.section

汇编代码中用于声明段时需要使用的伪指令。.text实际上写作.section.text，但其比较特殊可简写。使用.section声明的所有的段信息在编译后可通过执行命令来查看。
picture 1

.global

用于声明全局符号。可以被外部程序引用。

展开全文 >>

Android软件逆向权威指南读书笔记

第七章 ARM反汇编基础

android指令支持

这里只记我平时常用的两种架构

  1. armeabi-v7a

    • Thumb-2指令集扩展： 性能堪比32位ARM指令，简洁性类似于之前16位的Thumb指令集，同时支持16位与32位指令集的混合使用。
    • VFP硬件FPU指令：包括VFPv3-D16,除了ARM核心中的16个32位寄存器，还包含16个专用的64位浮点寄存器。
      同时支持可选扩展NEON、VFPv3-D32和ThumbEE, armeabi-v7a已经被并入AArch32架构。

  2. arm64-v8a
    兼容armabi-v7a,并支持AArch64架构，VFP扩展升级为v4版本， NEON指令集扩展是必需的。
    64位arm64-v8a规格的处理器支持AArch64和AArch32两种运行模式。
    在AArch64下，所有代码数据寻址采用64位地址空间，寄存器也采用64位的。

在AArch32模式为32位，因此，在此模式下代码数据寻址和寄存器的使用与之前一样，才有32位的。

因此，arm64-v8a完全兼容armeabi-v7a。

ARM原生程序的生成过程

  1. 编写代码

  1. 编译代码
    编写完代码之后需要进行代码的编译，此处跟书本不一样，主要采用clang,此处采用官网的说明，而书中采用的是gcc
    Android NDK编译

    从 NDK r19 开始，NDK 默认安装的工具链可供使用。与任意构建系统进行交互时不再需要使用 make_standalone_toolchain.py 脚本。为了确保使用正确的架构进行构建，请在调用 Clang 时使用 -target 传递适当的目标，或调用具有目标前缀的 Clang。例如，若要为 64 位 ARM Android 编译值为 21 的 minSdkVersion，可使用以下两种方法，您可以选择使用其中最方便的方法

     $ $NDK/toolchains/llvm/prebuilt/$HOST_TAG/bin/clang++ -target aarch64-linux-android21 foo.cpp

 $ $NDK/toolchains/llvm/prebuilt/$HOST_TAG/bin/aarch64-linux-android21-clang++ foo.cpp

    picture 1

    picture 2

    如上图，执行完这一句之后sum.cpp已经被编译完成。

  2. 完成代码的预处理

    预处理阶段，编译器将代码中的预处理指令进行处理。例如#include 中包含的头文件会全部编译进来，#define预定义、#if预条件处理等也都会在这里被编译器处理。详细的输出信息通过-E进行查看。

clang++ -E -fPIE file.cpp -o file.i

相应的.i文件的内容如下，由于我包含了一个iostream，结果几行代码，预编译之后变成了将近30000行。
picture 3

  1. 编译
    该阶段会进行语法等代码规范性检查，检查无误会把代码翻译成ARM汇编代码，输出信息通过-s选项进行查看。
    clang++ file.i -S -fPIE -o file.s执行该命令后会生成file.s的汇编文件。
    picture 4

  2. 汇编
    汇编阶段主要用来将汇编文件生成目标文件。
    clang++ -c file.s -o file.o

picture 5

  1. 链接
    将所有的目标合并，生成最终的可执行程序或动态链接库。
    clang++ file.o -fPIE -o file

Arm汇编基本语法

.text

在编译后用于存放代码的代码段。位于ARM EABI的ELF中。

.rodata

用于存放数据的数据段。位于ARM EABI的ELF中。

.section

汇编代码中用于声明段时需要使用的伪指令。.text实际上写作.section.text，但其比较特殊可简写。使用.section声明的所有的段信息在编译后可通过执行命令来查看。
picture 1

.global

用于声明全局符号。可以被外部程序引用。

展开全文 >>

runJava层调用栈追踪

调用过程：
java.lang.Thread

（实现接口的情况）run() => 有target => 运行target的run方法 => 直到start()开始创建线程 => nativeCreate(this, stackSize, daemon) 传递Thread对象， stackSize新线程所需的堆栈大小，该参数为0将被忽略。daemon是否是守护线程

java_lang_Thread.cc

Thread_nativeCreate(JNIEnv* env, jclass, jobject java_thread, jlong stack_size, jboolean daemon) => Thread::CreateNativeThread(env, java_thread, stack_size, daemon == JNI_TRUE) =>

Thread_nativeCreate(JNIEnv* env, jclass, jobject java_thread, jlong stack_size, jboolean daemon)
picture 1
不允许其在孵化器Zygote期间创建线程，否则将报错终止整个线程创建。检查结束后会直接调用CreateNativeThread,见名知意，该函数内部有创建线程。

void Thread::CreateNativeThread(JNIEnv* env, jobject java_peer, size_t stack_size, bool is_daemon) 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
CHECK(java_peer != nullptr);
 Thread* self = static_cast<JNIEnvExt*>(env)->GetSelf();

 if (VLOG_IS_ON(threads)) {
   ScopedObjectAccess soa(env);

   ArtField* f = jni::DecodeArtField(WellKnownClasses::java_lang_Thread_name);
   ObjPtr<mirror::String> java_name =
       f->GetObject(soa.Decode<mirror::Object>(java_peer))->AsString();
   std::string thread_name;
   if (java_name != nullptr) {
     thread_name = java_name->ToModifiedUtf8();
   } else {
     thread_name = "(Unnamed)";
   }

   VLOG(threads) << "Creating native thread for " << thread_name;
   self->Dump(LOG_STREAM(INFO));
 }

先检查java.lang.Thread对象是否存在，然后从该对象当中取出名字并转成Utf8的字符串，如果名字不存在则该对象的名字被命名为(Unnamed)。然后进行一些状态检查。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Runtime* runtime = Runtime::Current();

  // Atomically start the birth of the thread ensuring the runtime isn't shutting down.
  bool thread_start_during_shutdown = false;
  {
    MutexLock mu(self, *Locks::runtime_shutdown_lock_);
    if (runtime->IsShuttingDownLocked()) {
      thread_start_during_shutdown = true;
    } else {
      runtime->StartThreadBirth();
    }
  }
  if (thread_start_during_shutdown) {
    ScopedLocalRef<jclass> error_class(env, env->FindClass("java/lang/InternalError"));
    env->ThrowNew(error_class.get(), "Thread starting during runtime shutdown");
    return;
  }

获取当前的线程，并加上锁。当前线程终止则return

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Thread* child_thread = new Thread(is_daemon);
// Use global JNI ref to hold peer live while child thread starts.
child_thread->tlsPtr_.jpeer = env->NewGlobalRef(java_peer);
stack_size = FixStackSize(stack_size);

// Thread.start is synchronized, so we know that nativePeer is 0, and know that we're not racing
// to assign it.
env->SetLongField(java_peer, WellKnownClasses::java_lang_Thread_nativePeer,
                  reinterpret_cast<jlong>(child_thread));

// Try to allocate a JNIEnvExt for the thread. We do this here as we might be out of memory and
// do not have a good way to report this on the child's side.
std::string error_msg;
std::unique_ptr<JNIEnvExt> child_jni_env_ext(
    JNIEnvExt::Create(child_thread, Runtime::Current()->GetJavaVM(), &error_msg));

给创建的Thread对象赋值一个全局的JNI ref，给即将创建的子线程分配内存空间。注意：此时线程还没创建。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
int pthread_create_result = 0;
if (child_jni_env_ext.get() != nullptr) {
  pthread_t new_pthread;
  pthread_attr_t attr;
  child_thread->tlsPtr_.tmp_jni_env = child_jni_env_ext.get();
  CHECK_PTHREAD_CALL(pthread_attr_init, (&attr), "new thread");
  CHECK_PTHREAD_CALL(pthread_attr_setdetachstate, (&attr, PTHREAD_CREATE_DETACHED),
                     "PTHREAD_CREATE_DETACHED");
  CHECK_PTHREAD_CALL(pthread_attr_setstacksize, (&attr, stack_size), stack_size);
  pthread_create_result = pthread_create(&new_pthread,
                                         &attr,
                                         Thread::CreateCallback,
                                         child_thread);
  CHECK_PTHREAD_CALL(pthread_attr_destroy, (&attr), "new thread");

  if (pthread_create_result == 0) {
    // pthread_create started the new thread. The child is now responsible for managing the
    // JNIEnvExt we created.
    // Note: we can't check for tmp_jni_env == nullptr, as that would require synchronization
    //       between the threads.
    child_jni_env_ext.release();  // NOLINT pthreads API.
    return;
  }
}

可以看到这里开始创建了线程pthread_create(&new_pthread, &attr, Thread::CreateCallback, child_thread);

展开全文 >>

抓包全解

trace socket

TCP trace

首先我们用flask搭建一个小型服务器供我们收发手机的请求，此处上网随便扒拉一段代码直接run就可以启动了

1
2
3
4
5
6
7
8
9
10
from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello_world():
    return 'Hello, World!'

if __name__ == "__main__":
    app.run(host='0.0.0.0', port='9999')

接着写个程序用于收发TCP socket到这个服务器上，具体过程略

picture 1
这里创建一个线程，通过new Socket(ip, port)的形式生成一个Socket对象，并获取其OutputStream，InputStream,这两个对象用于后续收发包，要细讲太浪费时间了略过，直接发送一个包。

连接

以下堆栈都在java.net.Socket里
new Socket(ip, port) -> public Socket(String host, int port) -> private Socket(InetAddress[] addresses, int port, SocketAddress localAddr, boolean stream) throws IOException ->new SocksSocketImpl()
这个SocksSocketImpl是Socket类的一个属性，但是具体的操作都是由其完成的。
picture 3

其创建位置就在上图框住的位置。我们接着走到connect那里，也就是上图的位置，来到这里
public void connect(SocketAddress endpoint) throws IOException -> connect(endpoint, 0); -> public void connect(SocketAddress endpoint, int timeout) throws IOException ->impl.connect(epoint, timeout) -> protected abstract void connect(SocketAddress address, int timeout) throws IOException;

到这里是一个抽象方法，不可能通过这个抽象方法来执行的，这里SocksSocketImpl就开始起作用了。

以下堆栈都在java.net.SocksSocketImpl里
protected void connect(SocketAddress endpoint, int timeout) throws IOException 跟进来
picture 4
先找一找具体的逻辑。上面这部分没执行

F7步进的时候发现跳到了这里来了protected void connect(SocketAddress var1, int var2) throws IOException
这里函数是在AbstractPlainSocketImpl类里，SocksSocketImpl的父类PlainSocketImpl继承了这个方法，也就是说
picture 1

这里被调用了！

picture 2
然后跳转到java.net.AbstractPlainSocketImpl里的这个方法this.connectToAddress(this.address, this.port, var2);这里也能作为一个小的hook点，用来获取连接的地址和端口。该方法又会跳转到this.doConnect(InetAddress.getLocalHost(), var2, var3); -> synchronized void doConnect(InetAddress var1, int var2, int var3) throws IOException
picture 3
该类又会先检查是否有Tcp已经在连接，若有直接进行复用。
public static void beforeTcpConnect(FileDescriptor var0, InetAddress var1, int var2) throws IOException -> provider.implBeforeTcpConnect(var0, var1, var2);

接着会跳转到provider的实现类sun.net.sdp.SdpProvider
public void implBeforeTcpConnect(FileDescriptor var1, InetAddress var2, int var3) throws IOException ->

检查完之后，倘若没有则会使用java.net.PlainSocketImpl里的
this.socketConnect(var1, var2, var3) -> native void socketConnect(InetAddress var1, int var2, int var3) throws IOException;

以上就是Java层连接的大致流程，简要的分析下可以找到很多hook点，这些hook点主要用来hook连接的ip和port，实际上只需要hook java.net.PlainSocketImpl.socketConnect即可得到，因为这是必经之路是java和jni的分界点，但是如果不走java层的话就不会走上面的这些点，但是jni层也有很多这样的点可以hook到，可以说跟脱壳一样，存在海量的hook点，对抗将一直下去。

Hook一下证明这个点是可以hook到的。
picture 4
哈哈，没问题~

发送数据

outputstream.write(crypt.getBytes(“utf-8”));
|
V
public void write(byte[] var1) throws IOException
|
V
private void socketWrite(byte[] var1, int var2, int var3) throws IOException
|
V
private native void socketWrite0(FileDescriptor var1, byte[] var2, int var3, int var4) throws IOException;

上面是粗略的调用栈，具体是哪里去实现并发送的呢？刚才上面实际上也说了Socket类的具体发送实际上是OutputStream，InputStream,这两个对象用于后续收发包。我们可以先去看看SocksSocketImpl中的OutputStream
picture 5

看截图，要获取OutputStream可以从这个函数入手，而这个函数实际上返回的是一个java.net.SocketOutputStream类，那我们就按上面的发包处看。
public void write(byte[] var1) throws IOException -> this.socketWrite(var1, 0, var1.length); -> private void socketWrite(byte[] var1, int var2, int var3) throws IOException -> this.socketWrite0(var4, var1, var2, var3); -> private native void socketWrite0(FileDescriptor var1, byte[] var2, int var3, int var4) throws IOException;

好家伙，又遍历到java层到native层的分界处了，那理论上来说，这个就是必经的发包处了（除非直接调jni或者系统的函数）！
hook之~
picture 6
down!

附赠此处完整代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
function hook(){
    Java.perform(function(){

        var PlainSocketImplClass = Java.use("java.net.PlainSocketImpl");
        // native void socketConnect(InetAddress var1, int var2, int var3) throws IOException;
        PlainSocketImplClass.socketConnect.implementation = function(var1, var2, var3){
            console.log('socketConnect arg1 InetAddress: ', var1);
            console.log('socketConnect arg2 int: ', var2);
            console.log('socketConnect arg3 int: ', var3);
            this.socketConnect(var1, var2, var3);
        }

        var SocketOutputStreamClass = Java.use("java.net.SocketOutputStream");
        //     private native void socketWrite0(FileDescriptor var1, byte[] var2, int var3, int var4) throws IOException;

        //private void socketWrite(byte[] var1, int var2, int var3) throws IOException 这里可以看出发送的具体内容其实是byte[]数组
        SocketOutputStreamClass.socketWrite0.implementation = function(var1, var2, var3, var4){
            var content = converByteArray(var2);
            var socketimpl = this.impl.value;
            var address = socketimpl.address.value;
            var port = socketimpl.port.value;
            console.log("send address:" + address + ",port" + port + "\tCurrentThreadId[" + Process.getCurrentThreadId() + "]\tsend:" + content);
            this.socketWrite0(var1, var2, var3, var4)
        }
    })
}

function converByteArray(bytearray){
    var bytearrays = Java.array('byte', bytearray);
    var content = '';
    for (var i = 0;i < bytearrays.length; i++){
        content += String.fromCharCode(bytearray[i]);
    }
    return content;
}

function main(){
        hook();
}

setImmediate(main);

分析是这么个分析了，read也是这样分析的

接收数据

W/System.err: java.net.SocketTimeoutException: Read timed out
W/System.err: at java.net.SocketInputStream.socketRead0(Native Method)
W/System.err: at java.net.SocketInputStream.socketRead(SocketInputStream.java:114)
W/System.err: at java.net.SocketInputStream.read(SocketInputStream.java:170)
W/System.err: at java.net.SocketInputStream.read(SocketInputStream.java:139)
W/System.err: at java.net.SocketInputStream.read(SocketInputStream.java:125)
W/System.err: at com.example.okhttp.TcpClient$3.run(TcpClient.java:108)
W/System.err: at java.lang.Thread.run(Thread.java:764)
关键的代码

1
2
3
4
5
private native int socketRead0(FileDescriptor var1, byte[] var2, int var3, int var4, int var5) throws IOException;

private int socketRead(FileDescriptor var1, byte[] var2, int var3, int var4, int var5) throws IOException {
    return this.socketRead0(var1, var2, var3, var4, var5);
}

从以上的调用栈我们可以知道hook java.net.SocketInputStream.socketRead0即可得到信息（除非直接调jni或者系统的函数），就偷懒不写hook代码了，感兴趣的同学可以在找找其他hook点哦~

实际上最近很火的肉师傅的r0capture也是hook的这两个点，说明这两个点是真的很不错！
picture 7 

  var result = this.socketWrite0(fd, bytearry, offset, byteCount);

  var result = this.socketRead0(fd, bytearry, offset, byteCount, timeout);

人参数的意思都解释出来了，直接用就完事了~

trace SSL

本次trace采用okhttp3.2.0
okHttpClient.newCall(request); 生成Call对象之后采用异步的形式就用enqueue函数，采用同步就用execute函数。

具体执行是来自Call这个对象，是由OkHttpClient对象newCall生成的Call对象，我们跟进去。

-> return new RealCall(this, request);
然后我们调用了public void enqueue(Callback responseCallback)； 后面会来到 client.dispatcher().enqueue(new AsyncCall(responseCallback, forWebSocket));

这里要看看要跟哪里才能找到发包，先到enqueue
picture 2
是这个executorService()的execute函数执行了call，跟进去看看这个看看ExecutorService是啥
public interface ExecutorService extends Executor,是一个调度器的接口，这里的实现类是由OkHttpClient的内部类Build来创建的实现的。倘若没有在OkHttpClient对象进行Dispatcher赋值，则会默认new Dispatcher()来生成这个对象。
该类的executorService就是以下这些代码。

1
2
3
4
5
6
7
public synchronized ExecutorService executorService() {
  if (executorService == null) {
    executorService = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60, TimeUnit.SECONDS,
        new SynchronousQueue<Runnable>(), Util.threadFactory("OkHttp Dispatcher", false));
  }
  return executorService;
}

可以看到这个调度器实际上是一个线程池调度器。其具体的execute函数的逻辑我们可以不去考虑，先看到这个方法的声明：public void execute(Runnable command)，其参数是一个Runnable，这里可以跟AsyncCall串起来了final class AsyncCall extends NamedRunnable，实际上AsyncCall就是一个Runnable，其实也就是调用了AsyncCall里的run方法，其实是其父类的run方法。

1
2
3
4
5
6
7
8
9
@Override public final void run() {
  String oldName = Thread.currentThread().getName();
  Thread.currentThread().setName(name);
  try {
    execute();
  } finally {
    Thread.currentThread().setName(oldName);
  }
}

所以可以确定是发送的逻辑在AsyncCall的execute()里面。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
@Override protected void execute() {
  boolean signalledCallback = false;
  try {
    Response response = getResponseWithInterceptorChain(forWebSocket);
    if (canceled) {
      signalledCallback = true;
      responseCallback.onFailure(RealCall.this, new IOException("Canceled"));
    } else {
      signalledCallback = true;
      responseCallback.onResponse(RealCall.this, response);
    }
  } catch (IOException e) {
    if (signalledCallback) {
      // Do not signal the callback twice!
      logger.log(Level.INFO, "Callback failure for " + toLoggableString(), e);
    } else {
      responseCallback.onFailure(RealCall.this, e);
    }
  } finally {
    client.dispatcher().finished(this);
  }
}

也就是这段代码。

看命名可知主要的请求逻辑在这里面
-> getResponseWithInterceptorChain(forWebSocket);

1
2
3
4
private Response getResponseWithInterceptorChain(boolean forWebSocket) throws IOException {
  Interceptor.Chain chain = new ApplicationInterceptorChain(0, originalRequest, forWebSocket);
  return chain.proceed(originalRequest);
}

通过监听器来执行。

逻辑在这个ApplicationInterceptorChain对象里面.
-> public Response proceed(Request request) throws IOException

// No more interceptors. Do HTTP.
return getResponse(request, forWebSocket);

-> Response getResponse(Request request, boolean forWebSocket) throws IOException

engine = new HttpEngine(client, request, false, false, forWebSocket, null, null, null);

上面那个函数的上面这段代码超级重要，当时Hook HttpUrlConnection时看到其底层有出现过这个，我们看看下面的代码有调用其sendRequest()
picture 3
我们跟进去。
picture 4
下面的代码都在创建Response对象了，说明具体的请求可能就在 Request request = networkRequest(userRequest);
跟进去。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
private Request networkRequest(Request request) throws IOException {
  Request.Builder result = request.newBuilder();

  if (request.header("Host") == null) {
    result.header("Host", hostHeader(request.url(), false));
  }

  if (request.header("Connection") == null) {
    result.header("Connection", "Keep-Alive");
  }

  if (request.header("Accept-Encoding") == null) {
    transparentGzip = true;
    result.header("Accept-Encoding", "gzip");
  }

  List<Cookie> cookies = client.cookieJar().loadForRequest(request.url());
  if (!cookies.isEmpty()) {
    result.header("Cookie", cookieHeader(cookies));
  }

  if (request.header("User-Agent") == null) {
    result.header("User-Agent", Version.userAgent());
  }

  return result.build();
}

我们看到其实这里只是在构建请求相关的诸如请求头等东西，所以具体的逻辑不在这里，不用往下跟了，往回。
找到这里。 httpStream = connect();，凭名字盲猜我们想要的东西在里面，越来越接近了。

1
2
3
4
5
6
private HttpStream connect() throws RouteException, RequestException, IOException {
  boolean doExtensiveHealthChecks = !networkRequest.method().equals("GET");
  return streamAllocation.newStream(client.connectTimeoutMillis(),
      client.readTimeoutMillis(), client.writeTimeoutMillis(),
      client.retryOnConnectionFailure(), doExtensiveHealthChecks);
}

如果没猜错就是这个了
newStream里！

-> RealConnection resultConnection = findHealthyConnection(connectTimeout, readTimeout,
跟进findHealthyConnection,跟进直到
picture 6
picture 7
熟悉么，就是获取SocketImpl的地方。离答案越来越近了。跟进sink()
picture 8
这里返回的是一个包含完整write方法的一个Sink对象，这里有具体怎么发。我们在往回。
picture 9
这里有connectTls看看代码走不走这里！
picture 10
终于找到tls的握手的地方了！
picture 11
注意这个对象。ssl相关的对象，
picture 1
直接在跟进startHandshake(),见名知意，开始握手。我没找到其具体的实现逻辑，源码只能跟到某个jar包里，跳过这个不分析。
跟到下面
picture 4
看到截图这些注释，检车证书，然后保存握手，完成这些步骤没报错，则设置success = true；即为TLS完成。我们要知道okhttp发送实际上是在sink里完成的，source是用来接收的，我们再跟到sink函数里。
picture 9

picture 8

picture 5
终于找到你！！！！这个肯定也必须是发送数据的对象了！搜源码开始！

我搜的是aosp8.1的源码，发现迟迟没有找到OpenSSLSocketImpl的具体实现，结合刚才的CreateSocket找到OpenSSLSocketFactoryImpl
picture 10

原来OpenSSLSocketImpl在AOSP8.1开始变成了抽象类（AOSP8.0还是普通的类），通过工厂模式对其进行创建。这个真是一个坑，看源码的时候容易掉进去。
picture 11

创建的时候走的是4个参数的。

picture 12
也就是这里，所以具体的实现就在这两个当中选的。如果socket当中存在文件描述符则走第一个，没有走第二个，那我们分析随便选一个就行了。毕竟只想要tls握手前的数据。

我们直接找到SSLOutputStream这个内部类，因为后面的具体发送实际上交由这个内部类来完成。
picture 13

找到三个参数的位置。
HOOK之~
public void write(byte[] b, int off, int len) throws IOException

（中间有个小插曲，我用android7.1.2来hook半天没反应，后面发现自己是真的可爱）

picture 14
最好看看该APP加载了两个Socket中的哪个。

展开全文 >>

native层编程

静态加载

picture 1

picture 1

ABI

CPU的指令集，调用规范

lldb

llvm的一个组件，而llvm是编译市场的王者。可用来调试第三方的so库。在aosp源码当中tree -NCfhl |grep lldb找到lldb-server,32位和64位push到手机的/data/local/tmp,具体采用lldb的几位server,需要根据app的具体编译架构来决定。

交叉编译

用于编译第三方的c/c++的库，并能在android中使用。以下照搬官方的说明和使用方法

从 NDK r19 开始，NDK 默认安装的工具链可供使用。与任意构建系统进行交互时不再需要使用 make_standalone_toolchain.py 脚本。

为了确保使用正确的架构进行构建，请在调用 Clang 时使用 -target 传递适当的目标，或调用具有目标前缀的 Clang。例如，若要为 64 位 ARM Android 编译值为 21 的 minSdkVersion，可使用以下两种方法，您可以选择使用其中最方便的方法：

1
2
$ $NDK/toolchains/llvm/prebuilt/$HOST_TAG/bin/clang++ \
    -target aarch64-linux-android21 foo.cpp
1
2
$ $NDK/toolchains/llvm/prebuilt/$HOST_TAG/bin/aarch64-linux-android21-clang++ \
    foo.cpp

以上要编译c文件则需要把clang++替换成clang。
picture1

在这两种情况下，请将 $NDK 替换为指向 NDK 的路径，将 $HOST_TAG 替换为指向根据下表所下载的 NDK 的路径：

NDK 操作系统变体 主机标记
macOS darwin-x86_64
Linux linux-x86_64
32 位 Windows windows
64 位 Windows windows-x86_64

这里的前缀或目标参数的格式是目标三元组，带有表示 minSdkVersion 的后缀。该后缀仅与 clang/clang++ 一起使用；binutils 工具（例如 ar 和 strip）不需要后缀，因为它们不受 minSdkVersion 影响。Android 支持的目标三元组如下：

ABI 三元组
armeabi-v7a armv7a-linux-androideabi
arm64-v8a aarch64-linux-android
x86 i686-linux-android
x86-64 x86_64-linux-android

注意：对于 32 位 ARM，编译器会使用前缀 armv7a-linux-androideabi，但 binutils 工具会使用前缀 arm-linux-androideabi。对于其他架构，所有工具的前缀都相同。

许多项目的构建脚本都预计使用 GCC 风格的交叉编译器，其中每个编译器仅针对一种操作系统/架构组合，因此可能无法正常处理 -target。在这些情况下，最好使用三元组前缀的 Clang 二进制文件。

查看app的so在哪个目录下

  1. 打开app
  2. ps -e |grep -i 包名的关键字
  3. picture 1
    拿到其pid
  4. cat /proc/上面拿到的pid/maps | grep -i so名

picture 2

查看so的基地址

  1. 打开app
  2. ps -e |grep -i 包名的关键字拿到其pid
  3. ps -e|grep so名
    picture 2

基地址+偏移的计算

使用python
hex(0x基地址+0x偏移地址)
picture 3

so解密流程

  1. 定位到最细粒度的算法逻辑
  2. 确保算法里最好不要有任何第三方的调用，哪怕是libc的函数
  3. 模拟执行整个算法
  4. 模拟整个系统

3不行就4

ExAndroidNativeEmu

基于unicode的模拟器

花指令

旨在用于对抗反编译工具的指令

https://www.jianshu.com/p/0390f598c34c

手机装objdump

  1. 安装termux
  2. 在termux中pkg install binutils执行一遍这个命令,然后执行一下which objdump查看objdump的路径，如果还需要在执行什么命令安装会有提示的

GDB

GDB的优势
  1. 支持所有编译型语言
  2. 支持所有平台
  3. 可调内核（更传统legend）
  4. 内核硬件断点，开启内存断点
  5. 历史悠久
流程体验
  1. 在data/local/tmp下运行对应app的cpu下的gdbserver
    picture 2
    其中attach的是当前需要调试的app的pid。gdbserver端口默认23946
  2. 然后再kali中运行相应的gdb,此步骤只需运行gdb即可
    picture 1
  3. 然后运行target remote 手机ip:gdbserver端口，此时就连接到手机端的gdbserver，然后会看到一堆加载的so符号，等待这些符号刷完。

    获取顶层activity

    adb dumpsys activity top
HyperPwn调试

HyperPwn：GDB+GUI

安装

  1. 安装hyper
    安装这个版本的hyper-canary
    https://github.com/vercel/hyper/releases/tag/v3.1.0-canary.4
    picture 6

  2. dpkg -i hyper_3.1.0-canary.4_amd64.deb

可能会有依赖问题，需要到这个网去手动下载依赖。
https://www.debian.org/distrib/packages#search_packages

picture 7
picture 8
选择自己的PC架构下的包
picture 9

选个镜像站的源下载，然后dpkg -i 这个下载下来的包即可，如果这个包再报请重复刚才的步骤，直到我们想装的包装好。
picture 10

  1. 切到kali用户，并给chrome-sandbox赋权4755

chrome-sandbox位于/opt/Hyper下

然后注销当前root用户，切到kali

picture 11
此时hyper就安装好了

  1. 安装hyper插件
    （此时还在kali用户里）

安装插件需要科学，否则很有可能安装不成功，但是proxychains在这里用不了，需要把科学配成全局。
需要使用这个库redsocks,这个库最香的是kali自带了他，改改配置文件。

vi /etc/readsocks.conf
picture 12
然后再terminal输入redsocks直接就启动了。
picture 13
然后ss -lntp|more查看是否有在监听12345这个端口。

然后运行肉师傅给的脚步

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#不重定向目的地址为服务器的包
sudo iptables -t nat -A OUTPUT -d 192.168.179.1 -j RETURN  #请用你的shadowsocks服务器的地址替换$SERVER_IP
 
#不重定向私有地址的流量
sudo iptables -t nat -A OUTPUT -d 10.0.0.0/8 -j RETURN
sudo iptables -t nat -A OUTPUT -d 172.16.0.0/16 -j RETURN
sudo iptables -t nat -A OUTPUT -d 192.168.0.0/16 -j RETURN
 
#不重定向保留地址的流量,这一步很重要
sudo iptables -t nat -A OUTPUT -d 127.0.0.0/8 -j RETURN
 
#重定向所有不满足以上条件的流量到redsocks监听的12345端口
sudo iptables -t nat -A OUTPUT -p tcp -j REDIRECT --to-ports 12345 #12345是你的redsocks运行的端口,请根据你的情况替换它

修改shadowsocks那一行的ip即可

可以开始安装插件辣~
hyper i hyperinator

hyper i hyperpwn

分别运行这两行代码，安装好之后
picture 14
update一下hyper,倘若有通知弹出来说rawgithubuser ….这个的话可以看看这篇文章
https://www.cnblogs.com/sinferwu/p/12726833.html

查看so的所有符号

  1. 7z x 相应的apk
  2. nm -s 想查看的.so

导出所有的符号
nm -s 想查看的.so |grep method
picture 1

查看so的基址

picture 3

gdb查看相应函数的内容

示例：（两个相加的地址取自上图）
x/20i 0xbf0d6000+0x00002e38

下断点

b *(0xbf0d6000+0x00002e38)

也可以b 函数导出符号名

直接下段导出函数时，因为arm三级流水线（取值、译码、执行三者会同时执行）的关系,pc（程序计数器，主要用来存地址）需要+8

反编译某个导出函数

disassemble 导出函数名
例如
picture 1

hypepwn查看汇编上一次操作的值(快捷键)

ctrl+shift+PgUp
操作前：
picture 4

操作后:
picture 5

回到当前状态就是
ctrl+shift+PgDn

展开全文 >>

沙箱

Socket

由于工作需要加上想分析一下肉丝姐的r0capture,要想理解他的项目还是需要了解一下为什么要Hook这个地方，有什么含义，否则属于看看而已没法理解和学习大佬的精髓。

Socket类

xref: /libcore/ojluni/src/main/java/java/net/Socket.java

Socket类位于上面的位置。

阅读源码，首先从注释方面开始入手。
picture 1
该注释表明，Socket类其实实际上并不是真正干活的，真正干活的是SocketImpl。我们先到这个类去看看。

SocketImpl

picture 2
该类是一个抽象类，也就是说，要想使用该类必须实现其抽象方法，我们先看看其toString()，从toString()返回的结果可以获取到详细的该类的属性的含义。
picture 3

获取Socket的属性的函数为:

  • getInetAddress: 获取当前Socket的目标ip
  • getPort: 获取当前Socket的目标port
  • getLocalPort: 获取当前Socket的本地port

展开全文 >>

沙箱

沙箱的概念

对于系统来说，单个APP是没有隐私的，不管是脱壳、收发包，都是由系统的API来执行的。HOOK或者修改系统的API，就能得到很多APP的关键信息。

APP对抗沙箱
  1. 尽可能减少系统API的调用。比如Fultter，不调用系统的API进行网络通信。
  2. 尽可能自己实现一定量的算法；
  3. 对自己实现的算法进行强混淆。
  4. 增加自身算法的复杂度：VMP

基本上各大安全公司、杀毒软件公司都会有自己的沙箱，只要病毒、木马在自己的沙箱跑一遍，直接得到执行流、病毒相似性分析。对于APP也是一样的。

基于修改系统源码的沙箱的注意事项

  1. 基于源码的沙箱比基于HOOK的沙箱的一大好处是与环境高度集成，完全不需要考虑Hook的事情。

  2. 加固不会检测，也检测不到沙箱。

  3. 此类沙箱需要兼顾的考虑到风控，有些风控可能会检测相册的照片数量，或者是有没有常用的APP，或者恶意的（对于安全的而言）APP，所以可以下下一些生活中常用的诸如爱奇艺，网易云等常见APP放着。

甲方风控常见技术

展开全文 >>

Root原理及反制手段

什么是root

拥有最高权限的账户就叫root。

获取root的方式

  1. 提权
    利用Linux漏洞：adbd提权

全root: 有权限修改系统文件
半root（需解锁systemloac）:没有权限修改系统文件

半root直接刷magisk可实现全root

  1. 将su文件放到/system/bin或者/system/xbin目录
    执行su命令时，系统会去判断当前的uid、pid是否是管理员用户，如果是的话直接给true。
  2. 执行

检测root

  1. 检测su文件是否在/system/bin 或者 /system/xbin目录下存在

  2. 检测设备是否启动debugger模式

    1
    2
    3
    4
    5
    6
    7
    public static boolean checkDeviceDebugger(){
    	String buildTags = android.os.Build.TAGS;
    	if(buildTest != null && buildTags.contains("test-keys")){
    		return true;
    	}
    	return false;
    }

  3. 通过读取特征文件来判断是否存在root
    比如下面这段代码是用来判断是否安装了supersu的,因为该app会获取root权限，获取完成之后会把其自身变成系统级的apk，故可以检测出来相应的特征文件

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    public static boolean checkSuperuserApk(){
    	try{
    		File file = new File("/system/app/Superuser.apk");
    		if(file.exists()){
    			return true;
    		}
    	}catch(Exeception e){

    	}
    	return false;
    }

  4. 检测data的读写权限

    1

对抗检测root

  1. 把su文件进行编译，编译成其他文件比如msu等，执行时执行msu。

Stra1234

展开全文 >>

2W直播课

在手机上跑frida脚本，并开启服务

第一种方法，在termux直接跑frida

托Mac M1芯片的福，frida也支持了在ARM下直接运行，当然frida的版本必须在14以上，意味着可以在手机上直接跑frida 脚本和objection等等。frida的rpc暴露出相应的端口，可以直接跑。

termux里把python装上，然后装上adb，adb连127.0.0.1接口（记得打开wifiadb），然后找个窗口启动frida，之后即可按正常流程跑python 把rpc的接口暴露出来。

frida-net和frida

git clone

Ghidra

Ghidra是一款跟IDA一样用来进行逆向分析的软件，同样可以用来静态分析so，免费软件，新潮且受到大家追捧。

Ghidra官网:https://ghidra-sre.org/

可以到官网下载。下载之前，需要先装好高版本的openjdk,在Terminal处输入apt search openjdk来寻找openjdk的相应源
picture 1
这里我们选择jdk14。

省略apt install。。。。

git clone https://github.com/Ayrx/JNIAnalyzer.git下载这个项目，用来辅助我们在Ghidra上分析so。
我们先运行我们的Ghidra。
picture 2
第一次创建先创建一个新的项目。

之后来到这个页面，即可拖入so来进行分析。
picture 3
picture 4
效果还挺不错的，起码颜色我喜欢~

JNI Helper

该库是evilpan大神写的也是辅助我们在Ghidra上静态分析so的。

该库地址：https://github.com/evilpan/jni_helper

使用方法：
除了需要clone该库之外还要额外下载该库的Jadx的插件jar
picture 5
直接.zip下下来。

解压之后，先调用该jar包
picture 8

-ps : /root/apk/fulao2.apk是路径， fulao.json是出参。

运行完该条命令马上开始疯狂解析so。

然后还要安装Ghidra的插件，这个直接在我们的clone下来的项目里面找。
到该项目的ghidra项目下make install
picture 10

然后到ghidra下的这个位置
picture 11
点击，然后找到这个界面，随便找个灰色的地方右键
picture 12
picture 13
打钩
picture 14
出现打钩不了，像我截图这样，请重新启动ghidra!
picture 15
可以打钩了~
picture 16
然后就可以搜到我们的脚本了~

右键run script
picture 17
打开刚才生成的json文件。
picture 18
当当，有效果了~
picture 19
-ps : 没有动态调试，说明缺乏第三方工具，反编译效果跟IDA还是差了点，不过是新鲜事物，多个工具多个路子了~

jnitrace

https://github.com/chame1eon/jnitrace

该库可以hook所有jni函数。hook到之后会打印其参数返回值。

展开全文 >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

一只从Java到爬虫未来将会到安全的软件工程师。