前言

上次接触c++还是大一…那时看的飞快，现在发现c++的各种需求接踵而来….于是决定这俩个月狠过一遍c++ primer。如果进度允许的话再看看c++的技巧与模式。
主要从以下几方面入手：

1. 语法，c++的语法较为复杂，需要比较细节的记录
2. 底层实现，每章对应的语法点看下其反汇编的实现，着重逆向工程方面的问题。汇编以ARMv8与x86-64平台为准，编译器ndk-r16b，linux下为gcc7.3.0，gdb+ida分析
3. 设计模式，因为涉及到开发，因此特记下。主要分俩点：c++专有的设计问题(代码结构，文件内容、头文件规划等)；面向对象共有的设计模式(GOF)。

以primer5为基准，一章一篇记录

特点

基于经典编译器架构。LLVM的设计十分出色。其目标不是成为一个整体的编译器，而是被设计为一组库文件的集合，用于解决各种特定问题。比如优化器，每种优化便为一个.o文件，之间低耦合，可以针对不同需要选择不同的便。每遍称为Pass
因此用于构建jni等十分方便
前端：构建AST，转化为IR。
优化器: 针对IR进行优化
后端: 负责代码生成

前言

这段时间沉迷编译原理…踩了不少坑也涨了不少姿势…
一个项目：https://github.com/imbaya2466/java2native
用于java到本地代码的编译….写到最后基本就剩个基本的函数语句native化了….语法太庞大了根本写不动啊..

个人的小见解：

脚本语言 ：适合小型命令式快速脚本，依托于万能的库
面向对象语言 ：适合工程项目，易于建模。
过程语言 ： 贴近底层（汇编就是过程式的）全面控制计算机

建议： 一门万能语言c++ 、一门脚本语言py 、一门纯对象式语言java

前言

着重分析linux系统装载程序相关，涉及部分操作系统其它部分

android下与linux内核的版本对应：

来自：https://en.wikipedia.org/wiki/Android_version_history

分析的系统虽然是8.0的…手头的android源码不含内核…只能分析网上的4.4版本了：https://www.androidos.net.cn/kernel/4.4/xref

简介

转眼大三这次协会安全组的纳新该我上了……这里简单的记下安全组的表演内容，也算是没有空了这几天的内容

简介

开始使用C++来写程序了，这次没时间看primer了，先直接用它上手做东西，分析C++反汇编的时候再过一下primer中的语法点。毕竟语言还是要用才能熟。中间遇到的一些问题作为随笔先记录着

前情提要

需求想写不落地加载dex的壳，但是想要加载dex的同时还可以oat就必须涉及到hook了，于是决定彻底扫一遍hook。但看了几篇文后发现….ELF文件格式都忘了差不多了、linker与exec还没看…..
还是因为当初看的时候手太懒了没有动手写啊……….

于是先从一篇完整的elf文件格式解析写起
readelf真的好用……

hook基本都是c++写的，因此解析也用c++写好点
因为我的机子都是64位的，因此解析android arm-64位下的so为目的

由于许多书籍对elf中的名词描述不同，因此采用如下翻译：

此外本篇将地址区分为三种：
逻辑地址：指由程序产生的与段相关的偏移地址部分。也就是段*16+的那个值。
虚拟地址/线性地址：为进程虚拟的地址空间
物理地址：实际地址空间

现在从逻辑地址到虚拟地址还要经过一次保护模式分段机制。简述就是保护模式将段的信息存于GDT与LDT中，段寄存器存其表的索引值。
32位Linux中逻辑地址等于线性地址，因为Linux所有的段（用户代码段、用户数据段、内核代码段、内核数据段）的线性地址都是从 0x00000000 开始，长度4G，这样 线性地址=逻辑地址+ 0x00000000，也就是说逻辑地址等于线性地址了。
现在先认为elf中的都是虚拟地址。等搞清保护模式机制时阅读exec与linker再分析地址问题。64位下的机制貌似很不一样…….

ps:elf不是精灵的意思么….之后根据linker写elf壳的时候就叫darkelf好了….

加固技术

第一代加固技术——混淆技术；

第二代加固技术——加壳技术；

第三代加固技术——指令抽离；

第四代加固技术——指令转换，VMP；

接下来逐步实现一个自动化的加壳服务。
鉴于软件工程的重要性因此大致按着软工的步骤来，鉴于个人开发步骤有所删减

前言

本篇开始分析classloader。

参考：
https://blog.csdn.net/itachi85/article/details/78088701
https://blog.csdn.net/itachi85/article/details/78276837?utm_source=blogxgwz0
http://gityuan.com/2017/03/19/android-classloader/
https://www.jianshu.com/p/2f9b1d8be88d
https://www.jianshu.com/p/3912c05d257e
https://www.jianshu.com/p/20dcfcf27004
https://www.jianshu.com/p/b89d0b03e82c
http://liwenkun.me/2016/11/11/android-load-class-dynamically/

jvm

先从java虚拟机的类加载器讲起。以后再补java虚拟机的规范。

java虚拟机的系统加载器有：

Bootstrap ClassLoader（引导类加载器）
用C/C++代码实现的加载器，用于加载指定的JDK的核心类库，比如java.lang.、java.uti.等这些系统类。它用来加载以下目录中的类库：
$JAVA_HOME/jre/lib目录
-Xbootclasspath参数指定的目录
Java虚拟机的启动就是通过引导类加载器创建一个初始类来完成的。由于类加载器是使用平台相关的底层C/C++语言实现的， 所以该加载器不能被Java代码访问到。但是我们可以查询某个类是否被引导类加载器加载过。

Extensions ClassLoader（拓展类加载器）
用于加载 Java 的拓展类 ，用来提供除了系统类之外的额外功能。它用来加载以下目录中的类库：
加载$JAVA_HOME/jre/lib/ext目录
系统属性java.ext.dir所指定的目录。

Application ClassLoader（应用程序类加载器）
又称作System ClassLoader(系统类加载器)，这是因为这个类加载器可以通过ClassLoader的getSystemClassLoader方法获取到。它用来加载以下目录中的类库：
当前应用程序Classpath目录
系统属性java.class.path指定的目录

用户自定义加载器，则是通过继承 java.lang.ClassLoader类的方式来实现自己的类加载器。
除了 Bootstrap ClassLoader，Extensions ClassLoader和App ClassLoader也继承了java.lang.ClassLoader类。

类加载器查找Class所采用的是双亲委托模式，所谓双亲委托模式就是首先判断该Class是否已经加载，如果没有则不是自身去查找而是委托给父加载器进行查找，这样依次的进行递归，直到委托到最顶层的Bootstrap ClassLoader，如果Bootstrap ClassLoader找到了该Class，就会直接返回，如果没找到，则继续依次向下查找，如果还没找到则最后会交由自身去查找。
其父都是创建时存储的。

采取双亲委托模式主要有两点好处：

1. 避免重复加载，如果已经加载过一次Class，就不需要再次加载，而是先从缓存中直接读取。 因为所有加载器都被连接在了一起，加载类时一定先向上委托，再向下加载，因此保证了只加载一次
2. 更加安全，如果不使用双亲委托模式，就可以自定义一个String类来替代系统的String类，这显然会造成安全隐患，采用双亲委托模式会使得系统的String类在Java虚拟机启动时就被加载，也就无法自定义String类来替代系统的String类，除非我们修改 类加载器搜索类的默认算法。还有一点，只有两个类名一致并且被同一个类加载器加载的类，Java虚拟机才会认为它们是同一个类，想要骗过Java虚拟机显然不会那么容易。

前言

本篇继续探索oat文件的加载。先补充些内容：

ApplicationThread与Application不同。
ActivityThread内mAppThread是一个ApplicationThread类型的Binder对象，它的作用是用来进行进程间通信的。其继承于IApplicationThread.Stub
Application是继承ContextWrapper的组件，表示app，同样存于ActivityThread内mInitialApplication全局唯一

参考文：
http://gityuan.com/2017/04/09/android_context/
https://shuwoom.com/?p=142

几个关键的类：

1. ActivityThread：主线程，通过接受AMS的请求对Activity等组件进行控制。因此可以及时控制app。
2. Application：代表app对象，LoadedApk对象存于其中。
3. Instrumentation：用来监控系统和应用的交互常用于测试。
4. LoadedApk：当前加载的APK包的各种信息