new Runnable的方式创建启动线程

线程启动的开端实际上是.start()之后
然后走/art/runtime/native/java_lang_Thread.cc

1
2
3
4
5
6
7
8
9
10
11
12
13

static void Thread_nativeCreate(JNIEnv* env, jclass, jobject java_thread, jlong stack_size,
                                jboolean daemon) {
  // There are sections in the zygote that forbid thread creation.
  Runtime* runtime = Runtime::Current();
  if (runtime->IsZygote() && runtime->IsZygoteNoThreadSection()) {
    jclass internal_error = env->FindClass("java/lang/InternalError");
    CHECK(internal_error != nullptr);
    env->ThrowNew(internal_error, "Cannot create threads in zygote");
    return;
  }

  Thread::CreateNativeThread(env, java_thread, stack_size, daemon == JNI_TRUE);
}

/art/runtime/thread.cc

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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101

void Thread::CreateNativeThread(JNIEnv* env, jobject java_peer, size_t stack_size, bool is_daemon) {
  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));
  }

  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;
  }

  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));

  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;
    }
  }

  // Either JNIEnvExt::Create or pthread_create(3) failed, so clean up.
  {
    MutexLock mu(self, *Locks::runtime_shutdown_lock_);
    runtime->EndThreadBirth();
  }
  // Manually delete the global reference since Thread::Init will not have been run.
  env->DeleteGlobalRef(child_thread->tlsPtr_.jpeer);
  child_thread->tlsPtr_.jpeer = nullptr;
  delete child_thread;
  child_thread = nullptr;
  // TODO: remove from thread group?
  env->SetLongField(java_peer, WellKnownClasses::java_lang_Thread_nativePeer, 0);
  {
    std::string msg(child_jni_env_ext.get() == nullptr ?
        StringPrintf("Could not allocate JNI Env: %s", error_msg.c_str()) :
        StringPrintf("pthread_create (%s stack) failed: %s",
                                 PrettySize(stack_size).c_str(), strerror(pthread_create_result)));
    ScopedObjectAccess soa(env);
    soa.Self()->ThrowOutOfMemoryError(msg.c_str());
  }
}

以上代码在pthread_create函数执行之前，线程还是没有得到创建。其中，pthread_create函数的三个参数Thread::CreateCallback，

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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

void* Thread::CreateCallback(void* arg) {
  Thread* self = reinterpret_cast<Thread*>(arg);
  Runtime* runtime = Runtime::Current();
  if (runtime == nullptr) {
    LOG(ERROR) << "Thread attaching to non-existent runtime: " << *self;
    return nullptr;
  }
  {
    // TODO: pass self to MutexLock - requires self to equal Thread::Current(), which is only true
    //       after self->Init().
    MutexLock mu(nullptr, *Locks::runtime_shutdown_lock_);
    // Check that if we got here we cannot be shutting down (as shutdown should never have started
    // while threads are being born).
    CHECK(!runtime->IsShuttingDownLocked());
    // Note: given that the JNIEnv is created in the parent thread, the only failure point here is
    //       a mess in InitStackHwm. We do not have a reasonable way to recover from that, so abort
    //       the runtime in such a case. In case this ever changes, we need to make sure here to
    //       delete the tmp_jni_env, as we own it at this point.
    CHECK(self->Init(runtime->GetThreadList(), runtime->GetJavaVM(), self->tlsPtr_.tmp_jni_env));
    self->tlsPtr_.tmp_jni_env = nullptr;
    Runtime::Current()->EndThreadBirth();
  }
  {
    ScopedObjectAccess soa(self);
    self->InitStringEntryPoints();

    // Copy peer into self, deleting global reference when done.
    CHECK(self->tlsPtr_.jpeer != nullptr);
    self->tlsPtr_.opeer = soa.Decode<mirror::Object>(self->tlsPtr_.jpeer).Ptr();
    self->GetJniEnv()->DeleteGlobalRef(self->tlsPtr_.jpeer);
    self->tlsPtr_.jpeer = nullptr;
    self->SetThreadName(self->GetThreadName()->ToModifiedUtf8().c_str());

    ArtField* priorityField = jni::DecodeArtField(WellKnownClasses::java_lang_Thread_priority);
    self->SetNativePriority(priorityField->GetInt(self->tlsPtr_.opeer));

    runtime->GetRuntimeCallbacks()->ThreadStart(self);

    // Unpark ourselves if the java peer was unparked before it started (see
    // b/28845097#comment49 for more information)

    ArtField* unparkedField = jni::DecodeArtField(
        WellKnownClasses::java_lang_Thread_unparkedBeforeStart);
    bool should_unpark = false;
    {
      // Hold the lock here, so that if another thread calls unpark before the thread starts
      // we don't observe the unparkedBeforeStart field before the unparker writes to it,
      // which could cause a lost unpark.
      art::MutexLock mu(soa.Self(), *art::Locks::thread_list_lock_);
      should_unpark = unparkedField->GetBoolean(self->tlsPtr_.opeer) == JNI_TRUE;
    }
    if (should_unpark) {
      self->Unpark();
    }
    // Invoke the 'run' method of our java.lang.Thread.
    // 在JNI层与Java层函数进行交互时候需要获取Java的*jMethodID*,然后通过Call或者Invoke开头的函数来执行相应的Java函数
    ObjPtr<mirror::Object> receiver = self->tlsPtr_.opeer;
    jmethodID mid = WellKnownClasses::java_lang_Thread_run;
    ScopedLocalRef<jobject> ref(soa.Env(), soa.AddLocalReference<jobject>(receiver));
    InvokeVirtualOrInterfaceWithJValues(soa, ref.get(), mid, nullptr);
  }
  // Detach and delete self.
  Runtime::Current()->GetThreadList()->Unregister(self);

  return nullptr;
}

该方法实际上是在初始化和执行java.lang.Thread这个对象的run方法，也就是我们重写的run方法。从注释// Invoke the 'run' method of our java.lang.Thread.也能看出来。

由此我们可以得知，java的线程依附于JNI的线程来执行，并且run()函数实际上是在JNI层面上进行执行的，所以打印调用栈时，java.lang.Thread.run()总在调用栈的最开头，因为打印的调用栈是子线程的，子线程的执行的也就是run()函数。但是大部分时候我们也需要知道这个子线程执行的run()方法在哪个位置，然而这部分是在主线程创建Java的Thread对象附近，所以我们需要hook Thread的构造函数的地方来实现。

我们现在来看看Thread类的构造函数。
有若干个，但是最终都会调用private void init(ThreadGroup g, Runnable target, String name, long stackSize, AccessControlContext acc)

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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76

private void init(ThreadGroup g, Runnable target, String name,
                  long stackSize, AccessControlContext acc) {
    if (name == null) {
        throw new NullPointerException("name cannot be null");
    }

    this.name = name;

    Thread parent = currentThread();
    // Android-removed: SecurityManager stubbed out on Android
    // SecurityManager security = System.getSecurityManager();
    if (g == null) {
        // Android-changed: SecurityManager stubbed out on Android
        /*
        /* Determine if it's an applet or not *

        /* If there is a security manager, ask the security manager
           what to do. *
        if (security != null) {
            g = security.getThreadGroup();
        }

        /* If the security doesn't have a strong opinion of the matter
           use the parent thread group. *
        if (g == null) {
        */
            g = parent.getThreadGroup();
        // }
    }

    // Android-removed: SecurityManager stubbed out on Android
    /*
    /* checkAccess regardless of whether or not threadgroup is
       explicitly passed in. *
    g.checkAccess();

    /*
     * Do we have the required permissions?
     *
    if (security != null) {
        if (isCCLOverridden(getClass())) {
            security.checkPermission(SUBCLASS_IMPLEMENTATION_PERMISSION);
        }
    }
    */

    g.addUnstarted();

    this.group = g;
    this.daemon = parent.isDaemon();
    this.priority = parent.getPriority();
    // Android-changed: Moved into init2(Thread) helper method.
    /*
    if (security == null || isCCLOverridden(parent.getClass()))
        this.contextClassLoader = parent.getContextClassLoader();
    else
        this.contextClassLoader = parent.contextClassLoader;
    this.inheritedAccessControlContext =
            acc != null ? acc : AccessController.getContext();
    */
    this.target = target;
    // Android-removed: The priority parameter is unchecked on Android.
    // It is unclear why this is not being done (b/80180276).
    // setPriority(priority);
    // Android-changed: Moved into init2(Thread) helper method.
    // if (parent.inheritableThreadLocals != null)
    //     this.inheritableThreadLocals =
    //         ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);
    init2(parent);

    /* Stash the specified stack size in case the VM cares */
    this.stackSize = stackSize;

    /* Set thread ID */
    tid = nextThreadID();
}

pthread_create的具体执行线程函数实际上是这一块

找到相应函数所在位置看看这函数是啥意思

是通过汇编来调用CreateCallBack这个函数的，也就是说hook pthread_create是拿不到子线程的ThreadID而只要hook CreateCallBack这个函数即可拿到子线程的线程ID，而且该函数此时正在执行，Hook这个函数肯定比Socket收发点更快的拿到线程ID，然后等到Socket收发时就可以通过子线程ID来拿到具体的调用栈。

所以我们是不是只要hook这个函数就可以拿到具体的调用栈？let us try!

找到某被大佬们反复胖揍的违法APP

/external/webrtc/talk/app/webrtc/java/jni/jni_helpers.cc
该类中有详细的会帮助到我们的一些函数，使用时仅需引用#include <nativehelper/JNIHelp.h>

1. 获取当前线程ID

   1 2 3 4 5 6 7 8 9

   // Return thread ID as a string. static std::string GetThreadId() { char buf[21]; // Big enough to hold a kuint64max plus terminating NULL. RTC_CHECK_LT(snprintf(buf, sizeof(buf), "%ld", static_cast<long>(syscall(__NR_gettid))), sizeof(buf)) << "Thread id is bigger than uint64??"; return std::string(buf); }

jni层socket发包分析

/libcore/ojluni/src/main/native/SocketOutputStream.c:

1. SocketOutputStream_socketWrite0
   JNIEXPORT void JNICALL
   SocketOutputStream_socketWrite0(JNIEnv *env, jobject this,

                                          jobject fdObj,
                                          jbyteArray data,
                                          jint off, jint len)

本篇开始补一下两万班的作业，报了那么多个月了一直没写作业（捂脸），近期从公司离职准备远赴上海追梦学习，故要保持好状态，话不多说，冲！

题目要求

1. fulao算法接口在手机上用http暴露下
   （提示：使用frida-net库和frida-inject）
   https://github.com/frida/frida-net

2. fulao 加解密库的 native部分分析一下

3. 破解fulao的vip（任意一个功能均可）

目标分析

本次分析的apk属于带颜色的不法app，我们要以打击犯罪的角度来进行分析。
先走流程

抓包

当点开任意一个视频时：

这个payload是我们要找到的一个加密参数，碰到这种级别的app优先考虑使用r0capture,其可以直接找到相应的调用栈。

先看到文件名是DecryInterceptor，这不是解密的拦截器的意思嘛~静态分析看看。

静态分析

来到该类

该类的这个地方我比较的感兴趣，找到CipherClient.

这个类应该是我们需要的类了，看看其具体是用了什么加密

该类的具体的加密是在so当中，我们进so看看。

首先这个是静态注册的函数，静态注册有一个特点，Java_包名_类名_函数名为函数的名称。看下图我圈起来的部分按这个规律怎么拼出来so的静态注册的函数名。

Java_net_idik_lib_cipher_so_CipherCore_getString,看看IDA是不是这样。

是的没错~

分析so代码

F5之后代码被反编译如下

不反编译的话需要看汇编，由于我的汇编也是一坨shite,so不能用shite喂给新手朋友，所以f5大家一起分析一波，有问题请指正~

本人分析so是这样来看的，把JNIEnv*给转出来，然后得到相应的env->之后的函数名称，然后通过jni.h里的函数查看这些函数的参数的意思，以此辅助理解函数的意思，方便后面的主动调用或算法还原。

例如

可以看到第二个参数是jstring类型，所以a3就确定是我们传进来的String类型，那我们把这个a3的类型改成jstring(按Y，或者右键那个a3的变量Set lvar type),然后我们再把a3改一下名字（按n，或者右键Rename lvar），方便我们分析，这里是Java传进来待转换成char*的内容，那改个名字方便理解。

最好结合frida的inline-hook来配合IDA进行静态分析。

导读：

为啥要学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结果根据指令需求更改状态寄存器的条件位。

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

当通过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. 编写代码

2. 编译代码
   编写完代码之后需要进行代码的编译，此处跟书本不一样，主要采用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

   

   

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

3. 完成代码的预处理

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

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

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

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

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

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

Arm汇编基本语法

.text

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

.rodata

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

.section

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

.global

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

第七章 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. 编写代码

2. 编译代码
   编写完代码之后需要进行代码的编译，此处跟书本不一样，主要采用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

   

   

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

3. 完成代码的预处理

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

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

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

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

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

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

Arm汇编基本语法

.text

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

.rodata

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

.section

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

.global

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

调用过程：
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)

不允许其在孵化器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到这个服务器上，具体过程略

这里创建一个线程，通过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类的一个属性，但是具体的操作都是由其完成的。

其创建位置就在上图框住的位置。我们接着走到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 跟进来

先找一找具体的逻辑。上面这部分没执行

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

这里被调用了！

然后跳转到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

该类又会先检查是否有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到的。

哈哈，没问题~

发送数据

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

看截图，要获取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之~

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的这两个点，说明这两个点是真的很不错！

  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

是这个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()

我们跟进去。

下面的代码都在创建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,跟进直到


熟悉么，就是获取SocketImpl的地方。离答案越来越近了。跟进sink()

这里返回的是一个包含完整write方法的一个Sink对象，这里有具体怎么发。我们在往回。

这里有connectTls看看代码走不走这里！

终于找到tls的握手的地方了！

注意这个对象。ssl相关的对象，

直接在跟进startHandshake(),见名知意，开始握手。我没找到其具体的实现逻辑，源码只能跟到某个jar包里，跳过这个不分析。
跟到下面

看到截图这些注释，检车证书，然后保存握手，完成这些步骤没报错，则设置success = true；即为TLS完成。我们要知道okhttp发送实际上是在sink里完成的，source是用来接收的，我们再跟到sink函数里。

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

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

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

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

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

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

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

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

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

静态加载

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。

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

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

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

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

查看app的so在哪个目录下

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

查看so的基地址

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

基地址+偏移的计算

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

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
   
   其中attach的是当前需要调试的app的pid。gdbserver端口默认23946
2. 然后再kali中运行相应的gdb,此步骤只需运行gdb即可
   
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
   

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

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

选择自己的PC架构下的包

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

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

chrome-sandbox位于/opt/Hyper下

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

此时hyper就安装好了

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

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

vi /etc/readsocks.conf

然后再terminal输入redsocks直接就启动了。

然后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

分别运行这两行代码，安装好之后

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

查看so的基址

gdb查看相应函数的内容

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

下断点

b *(0xbf0d6000+0x00002e38)

也可以b 函数导出符号名

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

反编译某个导出函数

disassemble 导出函数名
例如

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

ctrl+shift+PgUp
操作前：

操作后:

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

Socket

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

Socket类

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

Socket类位于上面的位置。

阅读源码，首先从注释方面开始入手。

该注释表明，Socket类其实实际上并不是真正干活的，真正干活的是SocketImpl。我们先到这个类去看看。

SocketImpl

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

获取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放着。

甲方风控常见技术