Shunix's Weblog

深入应用冷启动优化

Shunix — Thu, 01 Oct 2020 06:17:00 GMT

背景

为什么做冷启动优化

冷启动时间是用户对app的第一印象，线上AB实验表明，冷启动时间会直接影响用户的留存。

冷启动时间口径

起点：Application#attachBaseContext()
结束时间：第一个Activity的onWindowFocusChanged()
为什么是这两个点？Application#attachBaseContext()是应用代码被执行的最早节点，第一个Activity的onWindowFocusChanged()是第一帧完成绘制的时间。
这里有一个小坑，之前Launcher Activity还是SplashActivity的时候，我们发现SplashActivity的onWindowFocusChanged()永远不会被执行，因为还没执行到onWindowFocusChanged()时，SplashActivity就finish了，因此我们的冷启动上报做在了MainActivity的onWindowFocusChanged()里，这也导致了之前版本线上数据偏高。

区分冷启动

首先我们来定义一下冷启动，冷启动指的是系统不存在应用进程的情况下，启动应用。如果我们只在SplashActivity或者MainActivity第一次创建时上报，以下几个场景会被误报成冷启动：

应用接收到广播，拉起了主进程，之后再点击桌面图标进入
主进程通过ContentProvider被拉起，之后再点击桌面图标进入
通过点击push进到了一个落地页，按返回键退出后，再点击桌面图标进入

要把冷启和非冷启最关键的差别，就在于Application是否需要创建。目前主端的做法是，在Application#onCreate()结束时，记一个时间ts1，在Launcher Activity#onCreate()开始时再记一个时间ts2，如果ts2 - ts1 < 200ms，就认为是冷启动。在大部分情况下，这个判断都是准确的，一定不会出现误报，但是通过点击push进落地页的情况，如果进程不存在也算冷启动，会漏报。
那么有没有一个完美的解决方案呢？我们先看一张应用冷启动的时序图：

我们知道，这里的消息都会被分发到ActivityThread的Handler上处理，关注两个消息，BIND_APPLICATION和EXECUTE_TRANSACTION，处理BIND_APPLICATION消息时，会调用Application#onCreate()方法，而这个时候，消息队列中已经有了EXECUTE_TRANSACTION消息，处理EXECUTE_TRANSACTION消息会创建Activity，走Activity的生命周期。所以只需要在Application#onCreate()方法中post一个消息到主线程，在这个消息中检测，如果已经有Activity创建过，那么就认为这是冷启动，前面说的几种情况：

广播导致的进程被拉起，因为没有创建Activity，因此不会上报冷启动
Content Provider导致的进程拉起同上
点击push进落地页的漏报，这个方案也能解决。

示例代码：

class MyApp : Application() {

  override fun onCreate() {
    super.onCreate()

    var firstActivityCreated = false

    registerActivityLifecycleCallbacks(object :
        ActivityLifecycleCallbacks {

      override fun onActivityCreated(
          activity: Activity,
          savedInstanceState: Bundle?
      ) {
        if (firstActivityCreated) {
          return
        }
        firstActivityCreated = true
      }
    })
    Handler().post {
      if (firstActivityCreated) {
        // 上报冷启动
      }
    }
  }}

误区

很多项目都做过启动优化，大部分都经历过如下阶段：

野蛮生长阶段，大量逻辑写在Application#onCreate()中，启动阶段串行执行
意识到问题，开始做启动阶段任务解耦，异步执行部分任务
引入启动任务调度框架，解决异步任务的时序和依赖问题
很多项目做到这里就结束了，在很多人的理解中，高度异步 == 总时间最短。这是一个想当然的结论，高度异步化之后依然有不少可改进的空间。

发现问题

从代码上来看，启动任务已经做到了高度并行，很难找到一些简单又见效快的手段，因此需要对启动过程做粒度更小的细分，找到可能的优化点。这里使用了systrace工具来分析启动阶段。

为什么用systrace

相比线上监控用的埋点，日志等方法，线下分析使用systrace能获得更全面的信息。systrace提供了全局的视角，能清楚的看到CPU当前负载以及调度情况，比如下面这个case：

这个启动任务的Wall Duration有112ms，如果通过打日志的方式，我们得到的结论就是这个任务耗时过长，但是从systrace上，我们看到CPU Duration只有18ms，真正占用了很多时间的，是多次锁的竞用。
因此这个任务优化的重点应该是解决锁竞用的问题，如果用打日志的方式，只能看到表面现象，很容易把优化方向带偏了。
如果是过度并行，导致很多任务在Runnable的状态等待CPU时间片，这种情况通过日志也会得出错误的信息，线下分析还是建议用systrace。

打开release systrace

看systrace建议使用release包，debug包的很多行为和release包不一样，一些步骤的耗时也很不一样，debug包得出的一些结论无法平移到release包，比如debug包dex加载时间会特别长，release没有这个问题，优化dex的ROI就很低。
release包默认是关闭了systrace的，在ActivityThread里有这么一段：

// Allow application-generated systrace messages if we're debuggable 
boolean isAppDebuggable = (data.appInfo.flags & ApplicationInfo.FLAG_DEBUGGABLE) != 0; 
Trace.setAppTracingAllowed(isAppDebuggable);

再看看Trace类：

/**
* Set whether tracing is enabled in this process.  Tracing is disabled shortly after Zygote
* initializes and re-enabled after processes fork from Zygote.  This is done because Zygote
* has no way to be notified about changes to the tracing tags, and if Zygote ever reads and
* caches the tracing tags, forked processes will inherit those stale tags.
*
* @hide
*/
public static void setTracingEnabled(boolean enabled, int debugFlags) {
    nativeSetTracingEnabled(enabled);
    sZygoteDebugFlags = debugFlags;

    // Setting whether tracing is enabled may change the tags, so we update the cached tags
    // here.
    cacheEnabledTags();
}

没有什么坑，只需要在Application#attachBaseContext反射调用这个方法，就可以打开release包的systrace。附上一个工具方法：

fun enableReleaseTrace() {
    try {
     Class.forName("android.os.Trace").getDeclaredMethod("setAppTracingAllowed", Boolean::class.java).invoke(null, true)
    } catch (tr: Throwable) {
        Log.e(TAG, Log.getStackTraceString(tr))
    }
}

分析现状

下面这张图是优化前的trace，只看主线程这根线，基本上都是绿色的，但是CPU存在两块区域有大量空白的时间片，分别对应的Application#attachBaseContext()之前，Application#attachBaseContext()和Application#onCreate()之间的时间。这两个时间片里，只有主线程在跑，没有利用好CPU。启动优化的本质，就是把CPU打满。

在ApplicationonCreate()之后，有两个TransactionExecutor.execute的tag，说明启动了两个Activity，低端机上创建Activity打来的开销非常明显：

然后还是上面这张图，在SplashActivity的创建过程中，出现了大段主进程的主线程在Sleeping的情况，但是这个时候并没有其他线程在执行任务，所以我们要从CPU入手。之前主线程运行在CPU3上，我们看看CPU3的时间片分配给谁了：

大量的时间片分给了我们应用的push进程，对应pid为32729，勾选上32729，刚好这段时间在做Application的创建：

再往后到Activity#onResume()之前的阶段：

布局的inflate占了大部分的时间，其中最长的这一条占用了234ms，也是一个优化收益比较大的地方。

优化手段

明确了问题之后，优化思路就很清晰了，优先解决下面几个问题：

打满Application创建阶段的CPU，避免出现大块空闲时间片
合并SplashActivity和MainActivity
启动阶段不要拉起子进程
缩短主线程inflate时间

打满Application创建阶段的CPU

这里要分两步来，分别解决我们前面发现的两段空闲时间片

利用好attachBaseContext()前的时间

从trace中可以看出，Application#attachBaseContext()之前的时间，只有主线程在执行，因为在调用super.attachBaseContext()之前，调用getApplicationContext()会为空，而很多SDK以及业务代码获取Context都是这么写的，之前我们所有的任务都是在调用了super.onAttachBaseContext()之后开始调度的，确实省事，但也浪费了这部分的时间片。所以这里我们做了个小改动，覆写了Application的getApplicationContext()方法

override fun getApplicationContext(): Context {
    return this
}

这么改之后，大部分获取Context的场景就没有问题了，但是如果获取的是baseContext，还是会有问题，在调用super.onAttachBaseContext()之前，ContextWrapper的mBase是没有赋值的。用到mBase的地方还是会挂掉，不过问题不大，attachBaseContext之前的一小段时间不算长，在这个阶段初始化也不是每个SDK都能适配，因此只选了一小部分任务，强制指定在这个阶段执行。

抹除attachBaseContext()结束到onCreate()开始前的gap

attachBaseContext()结束到onCreate()开始前还有一段时间，在我这台手机上大概是70ms左右，这段时间只有主线程在执行任务，其他线程时间片都浪费掉了。
上面两步做完后，CPU已经没有明显的大片空闲：

合并Activity

项目的SplashActivity仅仅是一个占位的Activity，当时做这个闪屏页是考虑到后续可能有开屏广告，运营活动之类的，想从一开始就把开屏逻辑和主页面分开，方便迭代维护。现在看起来是有点过度设计了，现在这个SplashActivity的作用就是展示一个开屏背景图，没有复杂逻辑。
然而启动一个Activity涉及到和AMS的IPC，资源加载，视图创建等，整体耗时在低端机上能有一两百毫秒，启动过程省掉一个Activity收益是很可观的。
因此，我们的SplashActivity为数不多的几行代码就整合进了MainActivity。冷启动时间在我这台手机上大概下降了100+ms，收益还是很可以的。

启动阶段不拉起子进程

从上面的trace中，我们可以看到CPU资源并不会因为新起一个进程而变成双份，启动阶段拉子进程一定会导致主进程时间片被抢。很多项目的Application中都会有关于进程的判断，如果非主进程，跳过一些逻辑，但这都是治标不治本的方法，fork进程，加载资源，加载类，这些都要CPU，还会造成一些IO。因此在启动阶段最好不要拉起子进程。经过评估，我们push进程的任务不需要这么早初始化，因此拉起子进程的任务在MainActivity的onWindowFocusChanged之后再开始调度。这一条的收益大概是50～100ms，波动比较大，不能精确量化。

Inflate优化

接下来我们解决主线程inflate耗时长的问题，布局Inflate本身就是一个很耗时的过程，中间涉及到读取XML文件，反射创建View等。所以Inflate优化一般有两个思路，一种是把XML布局转为对等的Java代码，另一种就是异步Inflate。转Java的方法比较复杂，要考虑兼容系统已有的一些逻辑，比如AppCompat的兼容转换等，经验数据是能节约2/3的inflate时间。这里要重点介绍的是异步Inflate的思路。
虽然Android的UI组件并不是线程安全的，但是Inflate在满足特定条件的情况下，是可以放在异步线程做的。Android SDK也提供了一个工具类AsyncLayoutInflater。一个Layout如果满足如下条件就可以被异步Inflate：

父布局的generateLayoutParams方法是线程安全的
包含的View不能在构造器中创建Handler或者获取Looper，因为非主线程没有创建Looper
XML中不包含Fragment

直接用官方的AsyncLayoutInflater，效果不会很好，AsyncLayoutInflater不允许设置Factory和Factory2，我们无法做到对Context的替换，这就意味着，我们最早也只能在Activity的onCreate()方法中开始异步Inflate，这个时间太晚了，很多时候异步线程还没来得及Inflate完，主线程已经要取了，这就会造成主线程等待，或者是主线程二次Inflate。而且Activity#onCreate的时候，CPU负载本来就比较重，增加并发任务不一定有效果，尤其在低端机上。可以看下面这张图，很明显可以看到一大段锁等待：

最理想的情况是在Application创建过程中就完成异步Inflate，进到Activity时，肯定有已经可用的结果。这就带来一个问题，Application里面的Context和Activity是不一样的，用Application的Context inflate出来的布局塞会Activity里会出问题，这就要求我们能做到Context的替换，结合Factory2和MutableContextWrapper，我们可以完成上述流程。
先是Factory2的代码：

class LInflateFactory : LayoutInflater.Factory2 {

    private val sClassPrefixList = arrayOf(
        "android.widget.",
        "android.view.",
        "android.webkit."
    )

    private val sConstructorSignature = arrayOf(Context::class.java, AttributeSet::class.java)

    private val sConstructorMap: ArrayMap> = ArrayMap()

    override fun onCreateView(
        parent: View?,
        name: String,
        context: Context,
        attrs: AttributeSet
    ): View? {
        var realName = name
        if (name == "view") {
            realName = attrs.getAttributeValue(null, "class")
        }
        return if (-1 == name.indexOf('.')) {
            for (i in sClassPrefixList.indices) {
                val view =
                    createViewByPrefix(context, attrs, realName, sClassPrefixList[i])
                if (view != null) {
                    return view
                }
            }
            null
        } else {
            createViewByPrefix(context, attrs, name, null)
        }
    }


    private fun createViewByPrefix(
        context: Context,
        attrs: AttributeSet,
        name: String,
        prefix: String?
    ): View? {
        var constructor = sConstructorMap[name]
        return try {
            if (constructor == null) {
                val clazz = Class.forName(
                    if (prefix != null) prefix + name else name,
                    false,
                    context.classLoader
                ).asSubclass(View::class.java)
                constructor = clazz.getConstructor(*sConstructorSignature)
                sConstructorMap[name] = constructor
            }
            constructor.isAccessible = true
            constructor.newInstance(MutableContextWrapper(context).apply {
                val originalTheme = context.packageManager.getApplicationInfo(packageName, 0).theme
                setTheme(originalTheme)
            }, attrs)
        } catch (e: Exception) {
            null
        }
    }



    override fun onCreateView(name: String, context: Context, attrs: AttributeSet): View? {
        return null
    }
}

在创建View的时候，我们把Context用MutableContextWrapper包了一层，这里要注意，theme要处理好，有一些View，比如AppBarLayout会检测theme是否正确，所以要从原来的context里把theme取出来，给MutableContextWrapper设置上。
然后是自定义的LayoutInflater：

class LLayoutInflater(context: Context) : LayoutInflater(context) {
    companion object {
        fun inflate(context: Context, @LayoutRes layoutId: Int): View {
            return LLayoutInflater(context).run {
                LayoutInflaterCompat.setFactory2(this, LInflateFactory())
                inflate(layoutId, null, false)
            }
        }
    }

    override fun cloneInContext(newContext: Context?): LayoutInflater {
        return LLayoutInflater(context)
    }
}

最后提供一个工具类，在取的时候传入Acitivity，自动完成context的替换：

object LAsyncInflateHolder {
    private val mPool = SparseArray()
    private val mLock = ReentrantLock()

    private const val TAG = "LAsyncInflate"

    fun asyncInflate(@LayoutRes layoutId: Int) {
        ThreadManager.inflateExecutor.submit {
            mLock.withLock {
                mPool.append(layoutId, LLayoutInflater.inflate(BaseApplication.instance, layoutId))
            }
        }
    }

    @UiThread
    fun tryGetView(activity: Activity, @LayoutRes layoutId: Int): View? {
        mLock.withLock {
            return if (mPool.indexOfKey(layoutId) < 0) {
                Log.d(TAG, "$layoutId null")
                null
            } else {
                val view = mPool[layoutId].apply {
                    (context as? MutableContextWrapper)?.baseContext = activity
                }
                mPool.remove(layoutId)
                view
            }
        }
    }
}

从trace里可以看到效果：

非必须任务延后

最后一项是偏业务的优化，应该从业务角度拆出来启动任务的优先级，这次启动优化，一共梳理了40+启动任务，有好几个都是没必要在启动阶段做的，完全可以放到业务使用时做懒加载，在增加启动任务时应该先考虑是不是一定要放在启动阶段初始化，能不能做懒加载？
从业务上来看，小概率场景需要的能力应该在用到时做懒加载，为了小部分用户牺牲大部分用户的体验是不划算的，研发在做业务开发时也要有这种意识。

效果

在Oppo 2G+8核联发科的手机上，启动时间从平均值2.22s降低到了1.58s左右
在小米MIX 2S（6G+骁龙845）上，启动时间均值0.51s

优化整体思路

不止局限于启动优化，性能优化的整体思路是通用的，可以归纳为如下流程：

线下观察的结果，因为人为误差或者机型不足的原因，可能不准确，一定要以线上数据为准。性能优化一般会涉及到业务的重构和改造，改的人不一定了解业务，QA的回归力度也不如之前业务开发的时候，所以灰度很有必要，观察有没有需要发版的问题。

防劣化

这里要重点说的就是防劣化，启动优化的防劣化要从两个方面入手，准入和持续监控。
我们项目把所有启动的Task收在一个包下，通过SPI的方式调用其他业务模块完成初始化，所以可以在MR的时候对这个包以及Application和MainActivity做强制CR，要求启动的owner通过后才能合入。这种力度的准入只能做到启动阶段不增加新任务，如果是已有的启动任务逻辑变更导致的性能劣化，通过CR很难发现，这就需要QA配合做持续的自动化测试。在git的pipeline中加入自动化也是很重要的防劣化手段。

可能的优化点

这次做启动优化的时间比较紧，只做了ROI高的部分，有一些因为优先级不高或者客观原因没有做的，我也列了下来，方便以后排技术需求或其他项目参考。

启动接口收敛

启动阶段网络请求应该收敛，可以通过延后请求或者接口合并的方式来做，需要服务端配合一起做，因为人力问题，暂未实现。

提前加载SharedPreferences

SP在第一次读取时，会一次性从磁盘读入内存，可以做预加载。因为项目业务代码已经全部使用了自研基于mmap的实现，未使用SP，只有部分二方三方库在使用SP，ROI较低。

提前加载启动阶段需要的类

开异步任务，提前用Class.forName()加载所有启动阶段用到的类。之前项目有用过，效果一般，能省个15～30ms左右，代价是非常难维护，需要用注解来标记每一个启动阶段要用到的类，或者自己维护列表。

Redex

接入Facebook的redex。时间比较紧张，没能对redex做技术预研，无法评估收益，担心影响线上稳定性，暂未使用。

关于SSL Pinning的一切

Shunix — Thu, 24 Sep 2020 10:24:50 GMT

背景

HTTPS当下已经非常普遍，HTTPS全称是Hypertext Transfer Protocol Secure，在HTTP基础上增加了TLS加密，虽然名字里有个Secure，但HTTPS并不是绝对安全的，依然存在被中间人攻击（
Man-in-the-middle attack）的风险，进而导致应用被抓包，HTTPS的加密流量被获取。

MITM中间人攻击

概念

这里举个简单的例子，帮助不了解MITM的读者理解：假如A和B需要通信，这个时候来了一个C，C告诉A自己是B，同时告诉B自己是A，A和B都以为自己在和对方通信，实际上看到的消息都是由C转发的，C就可以在这个过程中完成监听和篡改，这就是中间人攻击。

ARP欺骗

在真实的网络中，要完成上述的过程，需要借助ARP欺骗。ARP是局域网中用IP来查找MAC地址的协议，正常的ARP查找过程中，请求的主机会向局域网发送广播，查询对应IP的MAC地址，局域网的其他主机如果不是这个IP就会忽略请求，对应IP的主机会回应自己的MAC地址。但是ARP协议在机制上就没有考虑校验的情况，只要收到一个ARP回应，主机就会更新自己的ARP表。ARP协议的简单粗暴，让ARP欺骗变得非常简单。攻击者只需要往一个局域网不断发送ARP回应，就能更新各个主机的ARP表，从而达到上面一节说的目的，这个过程也被叫做ARP投毒。当然，更大范围的中间人攻击需要借助DNS投毒，这个就不细说，原理大致类似。

针对HTTPS的MITM

HTTPS在设计上是考虑到了中间人攻击的情况的，TLS是支持双向认证的（一般只需要客户端校验服务端身份），那么为什么还会存在中间人攻击的风险呢？TLS的认证机制是基于证书的，关于证书的细节我们会在后面的篇幅里细讲，这里不展开。我们如果没有信任一些奇奇怪怪的证书，TLS是可以保证通信安全的，否则就会导致TLS的认证机制失效，从而被中间人攻击。

抓包

抓包就是一个MITM的应用场景，这里以常用的Charles为例，看看HTTPS的加密是如何被绕过的。我们知道，如果要解密HTTPS流量，Charles会引导我们给手机安装一个根证书，用文本编辑器打开可以看出是标准的pem格式：

用openssl解析证书：

openssl x509 -text -in ~/Downloads/charles-ssl-proxying-certificate.pem

得到如下输出：

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:00:00:00:00:01:0f:86:26:e6:0d
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: OU=GlobalSign Root CA - R2, O=GlobalSign, CN=GlobalSign
        Validity
            Not Before: Dec 15 08:00:00 2006 GMT
            Not After : Dec 15 08:00:00 2021 GMT
        Subject: OU=GlobalSign Root CA - R2, O=GlobalSign, CN=GlobalSign
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a6:cf:24:0e:be:2e:6f:28:99:45:42:c4:ab:3e:
                    21:54:9b:0b:d3:7f:84:70:fa:12:b3:cb:bf:87:5f:
                    c6:7f:86:d3:b2:30:5c:d6:fd:ad:f1:7b:dc:e5:f8:
                    60:96:09:92:10:f5:d0:53:de:fb:7b:7e:73:88:ac:
                    52:88:7b:4a:a6:ca:49:a6:5e:a8:a7:8c:5a:11:bc:
                    7a:82:eb:be:8c:e9:b3:ac:96:25:07:97:4a:99:2a:
                    07:2f:b4:1e:77:bf:8a:0f:b5:02:7c:1b:96:b8:c5:
                    b9:3a:2c:bc:d6:12:b9:eb:59:7d:e2:d0:06:86:5f:
                    5e:49:6a:b5:39:5e:88:34:ec:bc:78:0c:08:98:84:
                    6c:a8:cd:4b:b4:a0:7d:0c:79:4d:f0:b8:2d:cb:21:
                    ca:d5:6c:5b:7d:e1:a0:29:84:a1:f9:d3:94:49:cb:
                    24:62:91:20:bc:dd:0b:d5:d9:cc:f9:ea:27:0a:2b:
                    73:91:c6:9d:1b:ac:c8:cb:e8:e0:a0:f4:2f:90:8b:
                    4d:fb:b0:36:1b:f6:19:7a:85:e0:6d:f2:61:13:88:
                    5c:9f:e0:93:0a:51:97:8a:5a:ce:af:ab:d5:f7:aa:
                    09:aa:60:bd:dc:d9:5f:df:72:a9:60:13:5e:00:01:
                    c9:4a:fa:3f:a4:ea:07:03:21:02:8e:82:ca:03:c2:
                    9b:8f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                9B:E2:07:57:67:1C:1E:C0:6A:06:DE:59:B4:9A:2D:DF:DC:19:86:2E
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl.globalsign.net/root-r2.crl

            X509v3 Authority Key Identifier:
                keyid:9B:E2:07:57:67:1C:1E:C0:6A:06:DE:59:B4:9A:2D:DF:DC:19:86:2E

    Signature Algorithm: sha1WithRSAEncryption
         99:81:53:87:1c:68:97:86:91:ec:e0:4a:b8:44:0b:ab:81:ac:
         27:4f:d6:c1:b8:1c:43:78:b3:0c:9a:fc:ea:2c:3c:6e:61:1b:
         4d:4b:29:f5:9f:05:1d:26:c1:b8:e9:83:00:62:45:b6:a9:08:
         93:b9:a9:33:4b:18:9a:c2:f8:87:88:4e:db:dd:71:34:1a:c1:
         54:da:46:3f:e0:d3:2a:ab:6d:54:22:f5:3a:62:cd:20:6f:ba:
         29:89:d7:dd:91:ee:d3:5c:a2:3e:a1:5b:41:f5:df:e5:64:43:
         2d:e9:d5:39:ab:d2:a2:df:b7:8b:d0:c0:80:19:1c:45:c0:2d:
         8c:e8:f8:2d:a4:74:56:49:c5:05:b5:4f:15:de:6e:44:78:39:
         87:a8:7e:bb:f3:79:18:91:bb:f4:6f:9d:c1:f0:8c:35:8c:5d:
         01:fb:c3:6d:b9:ef:44:6d:79:46:31:7e:0a:fe:a9:82:c1:ff:
         ef:ab:6e:20:c4:50:c9:5f:9d:4d:9b:17:8c:0c:e5:01:c9:a0:
         41:6a:73:53:fa:a5:50:b4:6e:25:0f:fb:4c:18:f4:fd:52:d9:
         8e:69:b1:e8:11:0f:de:88:d8:fb:1d:49:f7:aa:de:95:cf:20:
         78:c2:60:12:db:25:40:8c:6a:fc:7e:42:38:40:64:12:f7:9e:
         81:e1:93:2e

输出中是没有X509v3 Authority Key Identifier的字段的，根据RFC3280的定义，只有根证书允许省略这个字段：

The keyIdentifier field of the authorityKeyIdentifier extension MUST
be included in all certificates generated by conforming CAs to
facilitate certification path construction.  There is one exception;
where a CA distributes its public key in the form of a "self-signed"
certificate, the authority key identifier MAY be omitted.

所以这是一个自签名的根证书。当系统信任了根证书，那么根证书链下的所有子证书都会被认为合法，证书链的概念下面细说。Charles的抓包功能是通过中间人攻击来完成的，根证书被信任，那么Charles只要用一个子证书来欺骗被抓包的客户端，就能绕过TLS对中间人攻击的防护。
在Android 6.0之前，用户信任的CA证书会被认为是合法的，安装一个根证书就能解密所有App的HTTPS流量，6.0之后加了个限制，只有系统内置的CA证书被信任，开发中的应用需要手动信任用户添加的CA证书才行，这样就只有手动信任了证书的应用流量能被解密：



    
        example.com

那么有没有在高版本Android上全局抓包的方法呢？还真有，对于ROOT过的手机，我们可以导出.0格式的证书，放到系统的/etc/security/cacerts/目录下，这样就会被认为是系统内置CA证书，从而达到抓取所有应用HTTPS流量的目的。

TLS与证书

在讲本文的主题SSL Pinning之前，需要介绍一些背景知识，下面几节解释了TLS握手过程，以及证书的校验过程。

TLS握手

这里又要拿出Cloudflare的经典图了：

这里描述的是TLS1.3之前的情况，细节不再赘述，可以看我之前的文章：TLS握手过程，我们只需要注意其中一个重点：服务端会把自己的证书发送给客户端，而证书中包含了公钥信息。

证书校验

那么客户端得到证书是如何校验这个证书是合法的呢？这里就要引入证书链的概念，以Google为例：

可以看到，这里一共是有三级证书的，自底向上分别被称为最终实体证书，中间证书和根证书。把三个证书拖出来，分别存成文件:

证书都是cer后缀，我们尝试用DER解码，先看看最终实体证书：

openssl x509 -text -inform der -in ~/Downloads/\*.google.com.cer

输出如下信息：

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            31:79:87:25:0f:c0:be:e8:08:00:00:00:00:56:05:ed
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Google Trust Services, CN=GTS CA 1O1
        Validity
            Not Before: Aug 26 08:08:49 2020 GMT
            Not After : Nov 18 08:08:49 2020 GMT
        Subject: C=US, ST=California, L=Mountain View, O=Google LLC, CN=*.google.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:8e:14:e9:f8:bb:ae:1f:c4:64:53:b7:d6:7a:76:
                    50:8b:ab:05:c6:2e:71:32:e0:3e:db:ef:1e:5a:34:
                    43:a4:74:6a:2b:52:38:75:03:f0:2d:fa:e6:da:82:
                    10:92:53:9b:a0:0e:28:ea:61:68:2b:0c:6d:df:22:
                    da:5f:14:1b:90
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                96:65:7B:C2:08:15:03:E1:C3:F8:50:DD:8F:B6:73:65:43:DF:8C:80
            X509v3 Authority Key Identifier:
                keyid:98:D1:F8:6E:10:EB:CF:9B:EC:60:9F:18:90:1B:A0:EB:7D:09:FD:2B

            Authority Information Access:
                OCSP - URI:http://ocsp.pki.goog/gts1o1core
                CA Issuers - URI:http://pki.goog/gsr2/GTS1O1.crt

            X509v3 Subject Alternative Name:
                DNS:*.google.com, DNS:*.android.com, DNS:*.appengine.google.com, DNS:*.bdn.dev, DNS:*.cloud.google.com, DNS:*.crowdsource.google.com, DNS:*.datacompute.google.com, DNS:*.g.co, DNS:*.gcp.gvt2.com, DNS:*.gcpcdn.gvt1.com, DNS:*.ggpht.cn, DNS:*.gkecnapps.cn, DNS:*.google-analytics.com, DNS:*.google.ca, DNS:*.google.cl, DNS:*.google.co.in, DNS:*.google.co.jp, DNS:*.google.co.uk, DNS:*.google.com.ar, DNS:*.google.com.au, DNS:*.google.com.br, DNS:*.google.com.co, DNS:*.google.com.mx, DNS:*.google.com.tr, DNS:*.google.com.vn, DNS:*.google.de, DNS:*.google.es, DNS:*.google.fr, DNS:*.google.hu, DNS:*.google.it, DNS:*.google.nl, DNS:*.google.pl, DNS:*.google.pt, DNS:*.googleadapis.com, DNS:*.googleapis.cn, DNS:*.googlecnapps.cn, DNS:*.googlecommerce.com, DNS:*.googlevideo.com, DNS:*.gstatic.cn, DNS:*.gstatic.com, DNS:*.gstaticcnapps.cn, DNS:*.gvt1.com, DNS:*.gvt2.com, DNS:*.metric.gstatic.com, DNS:*.urchin.com, DNS:*.url.google.com, DNS:*.wear.gkecnapps.cn, DNS:*.youtube-nocookie.com, DNS:*.youtube.com, DNS:*.youtubeeducation.com, DNS:*.youtubekids.com, DNS:*.yt.be, DNS:*.ytimg.com, DNS:android.clients.google.com, DNS:android.com, DNS:developer.android.google.cn, DNS:developers.android.google.cn, DNS:g.co, DNS:ggpht.cn, DNS:gkecnapps.cn, DNS:goo.gl, DNS:google-analytics.com, DNS:google.com, DNS:googlecnapps.cn, DNS:googlecommerce.com, DNS:source.android.google.cn, DNS:urchin.com, DNS:www.goo.gl, DNS:youtu.be, DNS:youtube.com, DNS:youtubeeducation.com, DNS:youtubekids.com, DNS:yt.be
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.2
                Policy: 1.3.6.1.4.1.11129.2.5.3

            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl.pki.goog/GTS1O1core.crl

            1.3.6.1.4.1.11129.2.4.2:
.v.....7~.b....a...{7.V..&[...K.ATn...t*........G0E. .i...V.i.U....g..}"..d.6.../R.V+.!..X..#.....S.}..7../.l.V=G....d....GF0M..j-u....~f.HZ
    Signature Algorithm: sha256WithRSAEncryption
         2f:de:47:43:cd:2d:0a:ed:6f:6d:3c:4b:39:0e:e6:05:17:74:
         58:a7:33:f0:a1:10:0a:52:94:55:80:52:8a:5c:a0:88:73:35:
         55:cd:d9:51:72:de:c2:96:5c:52:83:f2:ca:05:a1:72:60:06:
         8e:da:4d:80:05:6a:60:fe:60:ab:cc:dc:02:67:84:41:47:cd:
         eb:af:80:6b:ec:d5:0d:6e:56:5a:bd:00:47:d8:62:2f:4c:01:
         93:76:10:bb:16:15:ca:d4:d9:b2:92:0e:5d:96:56:06:95:c3:
         a6:d6:77:fb:97:b6:2f:66:06:7c:0c:21:91:ac:8c:84:16:61:
         40:02:a9:f1:ca:62:e3:e0:72:da:7b:ab:3f:64:27:bb:d0:ff:
         de:a0:c4:6d:a3:72:1d:bc:0e:1d:a7:6a:07:15:69:70:aa:63:
         d2:68:ed:50:d2:44:c4:21:ca:b4:ec:73:0b:0c:b2:86:17:fa:
         cd:4a:ca:57:2c:56:9d:17:10:0e:68:ce:6d:e1:00:d4:65:f1:
         11:63:9f:e4:07:d9:fb:eb:36:7e:77:bc:94:a3:c5:04:8c:ca:
         fa:ec:7a:a3:33:fb:b1:65:82:d0:2b:e7:02:29:f9:c4:91:da:
         3e:62:3e:8a:da:29:c2:91:bb:60:cf:d6:d2:f4:5b:a5:19:37:
         b1:ae:b8:7e

信息量非常大，我们关注几个关键字段：
Signature Algorithm: sha256WithRSAEncryption表示证书的签名是先使用SHA256做摘要，再对摘要做RSA加密生成的。
Public Key Algorithm: id-ecPublicKey，表示公钥的算法是ECDSA,这是一个ECC证书，相比RSA算法，ECDSA的证书更小，运算也更快。
X509v3 Authority Key Identifier，不需要关心内容，有这个字段表示这不是自签名的根证书。
X509v3 Subject Alternative Name，这里包含了证书适用的域名。
最后还有一段Signature Algorithm，这就是证书的签名，配合前面的证书签名算法可以完成证书链的校验。
中间证书的结构大同小异，这里列出用于校验的关键信息：

Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d0:18:cf:45:d4:8b:cd:d3:9c:e4:40:ef:7e:b4:
                    dd:69:21:1b:c9:cf:3c:8e:4c:75:b9:0f:31:19:84:
                    3d:9e:3c:29:ef:50:0d:10:93:6f:05:80:80:9f:2a:
                    a0:bd:12:4b:02:e1:3d:9f:58:16:24:fe:30:9f:0b:
                    74:77:55:93:1d:4b:f7:4d:e1:92:82:10:f6:51:ac:
                    0c:c3:b2:22:94:0f:34:6b:98:10:49:e7:0b:9d:83:
                    39:dd:20:c6:1c:2d:ef:d1:18:61:65:e7:23:83:20:
                    a8:23:12:ff:d2:24:7f:d4:2f:e7:44:6a:5b:4d:d7:
                    50:66:b0:af:9e:42:63:05:fb:e0:1c:c4:63:61:af:
                    9f:6a:33:ff:62:97:bd:48:d9:d3:7c:14:67:dc:75:
                    dc:2e:69:e8:f8:6d:78:69:d0:b7:10:05:b8:f1:31:
                    c2:3b:24:fd:1a:33:74:f8:23:e0:ec:6b:19:8a:16:
                    c6:e3:cd:a4:cd:0b:db:b3:a4:59:60:38:88:3b:ad:
                    1d:b9:c6:8c:a7:53:1b:fc:bc:d9:a4:ab:bc:dd:3c:
                    61:d7:93:15:98:ee:81:bd:8f:e2:64:47:20:40:06:
                    4e:d7:ac:97:e8:b9:c0:59:12:a1:49:25:23:e4:ed:
                    70:34:2c:a5:b4:63:7c:f9:a3:3d:83:d1:cd:6d:24:
                    ac:07
                Exponent: 65537 (0x10001)

这一段给出了中间证书的公钥，因为是RSA算法，所以这里有一个Modulus和一个Exponent。最终实体证书的签名是用中间证书的私钥对最终实体证书的摘要加密得到，所以对应的解密过程是用中间证书的公钥解密最终实体证书的签名，能得出最终实体证书的摘要，如果能解密成功，就能确认最终实体证书确实是由中间证书签名的，再对最终实体证书做一次摘要，和解密出得摘要比对，如果一致即可确认证书没用被篡改过。
我们手动实现一下这个过程：
已知指数，模和密文，我们需要还原出原文，根据RSA算法，计算原文的算法如下，其中m是明文，c是密文，e是指数，n是模：

m = c ^ e (mod n)

代入上面证书里的值：

>>> n = 0x00d018cf45d48bcdd39ce440ef7eb4dd69211bc9cf3c8e4c75b90f3119843d9e3c29ef500d10936f0580809f2aa0bd124b02e13d9f581624fe309f0b747755931d4bf74de1928210f651ac0cc3b222940f346b981049e70b9d8339dd20c61c2defd1186165e7238320a82312ffd2247fd42fe7446a5b4dd75066b0af9e426305fbe01cc46361af9f6a33ff6297bd48d9d37c1467dc75dc2e69e8f86d7869d0b71005b8f131c23b24fd1a3374f823e0ec6b198a16c6e3cda4cd0bdbb3a4596038883bad1db9c68ca7531bfcbcd9a4abbcdd3c61d7931598ee81bd8fe264472040064ed7ac97e8b9c05912a1492523e4ed70342ca5b4637cf9a33d83d1cd6d24ac07
>>> e = 65537
>>> c = 0x2fde4743cd2d0aed6f6d3c4b390ee605177458a733f0a1100a52945580528a5ca088733555cdd95172dec2965c5283f2ca05a17260068eda4d80056a60fe60abccdc0267844147cdebaf806becd50d6e565abd0047d8622f4c01937610bb1615cad4d9b2920e5d96560695c3a6d677fb97b62f66067c0c2191ac8c8416614002a9f1ca62e3e072da7bab3f6427bbd0ffdea0c46da3721dbc0e1da76a07156970aa63d268ed50d244c421cab4ec730b0cb28617facd4aca572c569d17100e68ce6de100d465f111639fe407d9fbeb367e77bc94a3c5048ccafaec7aa333fbb16582d02be70229f9c491da3e623e8ada29c291bb60cfd6d2f45ba51937b1aeb87e
>>> pow(c, e, n)
986236757547332986472011617696226561292849812918563355472727826767720188564083584387121625107510786855734801053524719833194566624465665316622563244215340671405971599343902468620306327831715457360719532421388780770165778156818229863337344187575566725786793391480600129482653072861971002459947277805295727097226389568776499707662505334062639449916265137796823793276300221537201727072401742985542559596685092673521228140822200236743113743661549252453726123450722876929538747702356573783116197523966334991563351853851212597377279504828784763247643211048750059383511539240076118611220389103205312907651075225923933445
>>> print('0x%x' % pow(c, e, n))
0x1ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff003031300d060960864801650304020105000420cd55ba8e69bcc9a1c2aaba552982abd5519051f5708cb6f9885cd3a7d28cd505

最后这一段密文就是最终实体证书的摘要，我们再用openssl手动算一次摘要，看是否一致。先把证书转换成ANS.1格式，这是一种和protobuffer很相似的描述，都是tag, length, value的形式。

openssl asn1parse -inform der -in ~/Downloads/\*.google.com.cer

输出如下：

    0:d=0  hl=4 l=2416 cons: SEQUENCE
    4:d=1  hl=4 l=2136 cons: SEQUENCE
    8:d=2  hl=2 l=   3 cons: cont [ 0 ]
   10:d=3  hl=2 l=   1 prim: INTEGER           :02
   13:d=2  hl=2 l=  16 prim: INTEGER           :317987250FC0BEE808000000005605ED
   31:d=2  hl=2 l=  13 cons: SEQUENCE
   33:d=3  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption
   44:d=3  hl=2 l=   0 prim: NULL
   46:d=2  hl=2 l=  66 cons: SEQUENCE
   48:d=3  hl=2 l=  11 cons: SET
   50:d=4  hl=2 l=   9 cons: SEQUENCE
   52:d=5  hl=2 l=   3 prim: OBJECT            :countryName
   57:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :US
   61:d=3  hl=2 l=  30 cons: SET
   63:d=4  hl=2 l=  28 cons: SEQUENCE
   65:d=5  hl=2 l=   3 prim: OBJECT            :organizationName
   70:d=5  hl=2 l=  21 prim: PRINTABLESTRING   :Google Trust Services
   93:d=3  hl=2 l=  19 cons: SET
   95:d=4  hl=2 l=  17 cons: SEQUENCE
   97:d=5  hl=2 l=   3 prim: OBJECT            :commonName
  102:d=5  hl=2 l=  10 prim: PRINTABLESTRING   :GTS CA 1O1
  114:d=2  hl=2 l=  30 cons: SEQUENCE
  116:d=3  hl=2 l=  13 prim: UTCTIME           :200826080849Z
  131:d=3  hl=2 l=  13 prim: UTCTIME           :201118080849Z
  146:d=2  hl=2 l= 102 cons: SEQUENCE
  148:d=3  hl=2 l=  11 cons: SET
  150:d=4  hl=2 l=   9 cons: SEQUENCE
  152:d=5  hl=2 l=   3 prim: OBJECT            :countryName
  157:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :US
  161:d=3  hl=2 l=  19 cons: SET
  163:d=4  hl=2 l=  17 cons: SEQUENCE
  165:d=5  hl=2 l=   3 prim: OBJECT            :stateOrProvinceName
  170:d=5  hl=2 l=  10 prim: PRINTABLESTRING   :California
  182:d=3  hl=2 l=  22 cons: SET
  184:d=4  hl=2 l=  20 cons: SEQUENCE
  186:d=5  hl=2 l=   3 prim: OBJECT            :localityName
  191:d=5  hl=2 l=  13 prim: PRINTABLESTRING   :Mountain View
  206:d=3  hl=2 l=  19 cons: SET
  208:d=4  hl=2 l=  17 cons: SEQUENCE
  210:d=5  hl=2 l=   3 prim: OBJECT            :organizationName
  215:d=5  hl=2 l=  10 prim: PRINTABLESTRING   :Google LLC
  227:d=3  hl=2 l=  21 cons: SET
  229:d=4  hl=2 l=  19 cons: SEQUENCE
  231:d=5  hl=2 l=   3 prim: OBJECT            :commonName
  236:d=5  hl=2 l=  12 prim: UTF8STRING        :*.google.com
  250:d=2  hl=2 l=  89 cons: SEQUENCE
  252:d=3  hl=2 l=  19 cons: SEQUENCE
  254:d=4  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
  263:d=4  hl=2 l=   8 prim: OBJECT            :prime256v1
  273:d=3  hl=2 l=  66 prim: BIT STRING
  341:d=2  hl=4 l=1799 cons: cont [ 3 ]
  345:d=3  hl=4 l=1795 cons: SEQUENCE
  349:d=4  hl=2 l=  14 cons: SEQUENCE
  351:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Key Usage
  356:d=5  hl=2 l=   1 prim: BOOLEAN           :255
  359:d=5  hl=2 l=   4 prim: OCTET STRING      [HEX DUMP]:03020780
  365:d=4  hl=2 l=  19 cons: SEQUENCE
  367:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Extended Key Usage
  372:d=5  hl=2 l=  12 prim: OCTET STRING      [HEX DUMP]:300A06082B06010505070301
  386:d=4  hl=2 l=  12 cons: SEQUENCE
  388:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Basic Constraints
  393:d=5  hl=2 l=   1 prim: BOOLEAN           :255
  396:d=5  hl=2 l=   2 prim: OCTET STRING      [HEX DUMP]:3000
  400:d=4  hl=2 l=  29 cons: SEQUENCE
  402:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Key Identifier
  407:d=5  hl=2 l=  22 prim: OCTET STRING      [HEX DUMP]:041496657BC2081503E1C3F850DD8FB6736543DF8C80
  431:d=4  hl=2 l=  31 cons: SEQUENCE
  433:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Authority Key Identifier
  438:d=5  hl=2 l=  24 prim: OCTET STRING      [HEX DUMP]:3016801498D1F86E10EBCF9BEC609F18901BA0EB7D09FD2B
  464:d=4  hl=2 l= 104 cons: SEQUENCE
  466:d=5  hl=2 l=   8 prim: OBJECT            :Authority Information Access
  476:d=5  hl=2 l=  92 prim: OCTET STRING      [HEX DUMP]:305A302B06082B06010505073001861F687474703A2F2F6F6373702E706B692E676F6F672F677473316F31636F7265302B06082B06010505073002861F687474703A2F2F706B692E676F6F672F677372322F475453314F312E637274
  570:d=4  hl=4 l=1218 cons: SEQUENCE
  574:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Alternative Name
  579:d=5  hl=4 l=1209 prim: OCTET STRING      [HEX DUMP]:308204B5820C2A2E676F6F676C652E636F6D820D2A2E616E64726F69642E636F6D82162A2E617070656E67696E652E676F6F676C652E636F6D82092A2E62646E2E64657682122A2E636C6F75642E676F6F676C652E636F6D82182A2E63726F7764736F757263652E676F6F676C652E636F6D82182A2E64617461636F6D707574652E676F6F676C652E636F6D82062A2E672E636F820E2A2E6763702E677674322E636F6D82112A2E67637063646E2E677674312E636F6D820A2A2E67677068742E636E820E2A2E676B65636E617070732E636E82162A2E676F6F676C652D616E616C79746963732E636F6D820B2A2E676F6F676C652E6361820B2A2E676F6F676C652E636C820E2A2E676F6F676C652E636F2E696E820E2A2E676F6F676C652E636F2E6A70820E2A2E676F6F676C652E636F2E756B820F2A2E676F6F676C652E636F6D2E6172820F2A2E676F6F676C652E636F6D2E6175820F2A2E676F6F676C652E636F6D2E6272820F2A2E676F6F676C652E636F6D2E636F820F2A2E676F6F676C652E636F6D2E6D78820F2A2E676F6F676C652E636F6D2E7472820F2A2E676F6F676C652E636F6D2E766E820B2A2E676F6F676C652E6465820B2A2E676F6F676C652E6573820B2A2E676F6F676C652E6672820B2A2E676F6F676C652E6875820B2A2E676F6F676C652E6974820B2A2E676F6F676C652E6E6C820B2A2E676F6F676C652E706C820B2A2E676F6F676C652E707482122A2E676F6F676C656164617069732E636F6D820F2A2E676F6F676C65617069732E636E82112A2E676F6F676C65636E617070732E636E82142A2E676F6F676C65636F6D6D657263652E636F6D82112A2E676F6F676C65766964656F2E636F6D820C2A2E677374617469632E636E820D2A2E677374617469632E636F6D82122A2E67737461746963636E617070732E636E820A2A2E677674312E636F6D820A2A2E677674322E636F6D82142A2E6D65747269632E677374617469632E636F6D820C2A2E75726368696E2E636F6D82102A2E75726C2E676F6F676C652E636F6D82132A2E776561722E676B65636E617070732E636E82162A2E796F75747562652D6E6F636F6F6B69652E636F6D820D2A2E796F75747562652E636F6D82162A2E796F7574756265656475636174696F6E2E636F6D82112A2E796F75747562656B6964732E636F6D82072A2E79742E6265820B2A2E7974696D672E636F6D821A616E64726F69642E636C69656E74732E676F6F676C652E636F6D820B616E64726F69642E636F6D821B646576656C6F7065722E616E64726F69642E676F6F676C652E636E821C646576656C6F706572732E616E64726F69642E676F6F676C652E636E8204672E636F820867677068742E636E820C676B65636E617070732E636E8206676F6F2E676C8214676F6F676C652D616E616C79746963732E636F6D820A676F6F676C652E636F6D820F676F6F676C65636E617070732E636E8212676F6F676C65636F6D6D657263652E636F6D8218736F757263652E616E64726F69642E676F6F676C652E636E820A75726368696E2E636F6D820A7777772E676F6F2E676C8208796F7574752E6265820B796F75747562652E636F6D8214796F7574756265656475636174696F6E2E636F6D820F796F75747562656B6964732E636F6D820579742E6265
 1792:d=4  hl=2 l=  33 cons: SEQUENCE
 1794:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Certificate Policies
 1799:d=5  hl=2 l=  26 prim: OCTET STRING      [HEX DUMP]:30183008060667810C010202300C060A2B06010401D679020503
 1827:d=4  hl=2 l=  51 cons: SEQUENCE
 1829:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 CRL Distribution Points
 1834:d=5  hl=2 l=  44 prim: OCTET STRING      [HEX DUMP]:302A3028A026A0248622687474703A2F2F63726C2E706B692E676F6F672F475453314F31636F72652E63726C
 1880:d=4  hl=4 l= 260 cons: SEQUENCE
 1884:d=5  hl=2 l=  10 prim: OBJECT            :1.3.6.1.4.1.11129.2.4.2
 1896:d=5  hl=3 l= 245 prim: OCTET STRING      [HEX DUMP]:0481F200F0007600B21E05CC8BA2CD8A204E8766F92BB98A2520676BDAFA70E7B249532DEF8B905E000001742A06F9BD000004030047304502205BB262C173701DC2F4D182C34760FA693875B409B650DA2DBE966D80CB6EE9C8022100CFD52D39644158ED44F23ABE9B4746304D8CAB6A2D75DA92F0187E6688485A0D007600E712F2B0377E1A62FB8EC90C6184F1EA7B37CB561D11265BF3E0F34BF241546E000001742A06F9D2000004030047304502200B69DB8E9756FB698955FA04BF8467C80E7D22C2F364CD36DACDD72F52D1562B022100925882AA2314AAB3009F53A47D93CE377FCB2FCA6C1E563D4716ACEBF264E087
 2144:d=1  hl=2 l=  13 cons: SEQUENCE
 2146:d=2  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption
 2157:d=2  hl=2 l=   0 prim: NULL
 2159:d=1  hl=4 l= 257 prim: BIT STRING

再看看RFC5280的定义：

Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

   TBSCertificate  ::=  SEQUENCE  {
        version         [0]  EXPLICIT Version DEFAULT v1,
        serialNumber         CertificateSerialNumber,
        signature            AlgorithmIdentifier,
        issuer               Name,
        validity             Validity,
        subject              Name,
        subjectPublicKeyInfo SubjectPublicKeyInfo,
        issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3

第二行就是TBSCertificate的位置和长度，真正用来计算摘要的部分，偏移是4，hl=4表示header长度是4，l=2136表示内容长度是2136，总长度是2140，我们用dd提取出这部分，并对输出结果做SHA256摘要：

dd if=/Users/shunix/Downloads/\*.google.com.cer of=/Users/shunix/tmp/tbs skip=4 bs=1 count=2140
openssl dgst -sha256 ~/tmp/tbs

输出如下：

SHA256(/Users/shunix/tmp/tbs)= cd55ba8e69bcc9a1c2aaba552982abd5519051f5708cb6f9885cd3a7d28cd505

而上面我们用公钥解出来的摘要去掉前面的

0x1ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff003031300d060960864801650304020105000420

最后结果也是cd55ba8e69bcc9a1c2aaba552982abd5519051f5708cb6f9885cd3a7d28cd505，二者完全一致，说明最终实体证书没有被篡改过。
而中间证书和根证书的校验也是同样的过程，这里就不赘述。根证书是自签名的，甚至都可以不用签名，因为根证书是内置到系统里的。
CA之所以不直接从根证书发布最终实体证书是因为这样风险太大，一旦出现错误发布容易导致根证书不受信任，所以CA会从根证书发布中间证书，再从中间证书发布最终实体证书，完成自我隔离。当然，根证书也是有不被信任的先例的，比如Firefox和Chrome在2015年移除了对CNNIC根证书的信任，具体原因就不细讲了。

SSL Pinning

综上所述，有几种情况SSL是无法保证安全的：

某些wifi或者网站要求装个根证书才能继续使用，比如某订票网站
被信任的CA随意发布证书，比如赛门铁克，17年居然发布了example.com的证书，挺缺德的

所以客户端提供了一种额外的机制来保证HTTPS通信的安全，SSL Pinning，SSL Pinning又可以细分为Certificate Pinning和Public Key Pinning。

Certificate Pinning

Certificate Pinning也就是证书锁定，简单来说就是把证书文件打包进安装包，通过加载本地证书自定义TrustManager，进而创建自定义的SSLSocketFactory来完成的，这里贴一些关键代码：

fun loadCertificate(): Certificate {
    // 假设证书放在assets下
    return BaseApplication.instance.assets
        .open("shunix.cert").use { input ->
        CertificateFactory.getInstance("X.509").generateCertificate(input)
    }
}

fun getTrustManager(): TrustManager {
    val keyStore = KeyStore.getInstance(KeyStore.getDefaultType()).apply {
        setCertificateEntry("shunix", loadCertificate())
    }
    return TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm()).run {
        init(keyStore)
        trustManagers[0]
    }
}

fun getSSLSocketFactory(): SSLSocketFactory {
    val sslContext = SSLContext.getInstance("TLS").apply {
        init(null, arrayOf(getTrustManager()), null)
    }
    return sslContext.socketFactory
}

fallback策略

内置证书的方案存在一个问题，证书是会过期的，一般最终实体证书也就是一年的有效期，而中间证书和根证书有效期都是10年左右，超过绝大多数应用的生命周期了，所以一个比较简单的做法是同时内置中间证书或者根证书作为子证书过期的应对方案。中间证书和根证书一般都是同一个机构的，所以选哪一个并没有本质的区别，但是这样在安全性上会有一定的妥协，可以参考前面提到的赛门铁克和CNNIC证书，当根证书不被信任，一样会出问题，还有就是如果更换证书的CA也是做不到的，局限性很大。
那么能不能只内置最终实体证书，同时能解决有效期的问题呢？很自然地会想到动态更新本地证书，那就带来了另一个问题，如何保证本地证书更新的安全性呢？这是一个鸡生蛋蛋生鸡的问题，其实不讲究点，更新证书的请求可以直接走没有证书锁定的HTTPS完成，因为HTTPS被劫持本身就是小概率情况。如果追求完美的话，有一个比较麻烦的解决方案，就是再打包一个自签名的证书到安装包，锁定这个自签名的证书来更新最终实体证书，自签名证书有效期可以自定义，定的足够长就好，当然服务端也许要做相应改造，是否需要这么严格的安全策略就看业务场景了。

Public Key Pinning

Certificate Pinning实现过于繁琐，同时局限性比较大，所以就有了锁定Subject Public Key Info的实现。申请过证书的都知道，需要提供算法和公钥，即使更换新证书，这两个东西也是可以保持不变的，Android 7.0以上提供了非常方便的实现，只需要在res/xml/network_security_config.xml里加如下配置：



    
        example.com
        
            7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=
            
            fwza0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1oE=

可以参考Android官方文档：https://developer.android.com/training/articles/security-config#CertificatePinning
这里pin的是Base64编码后的Subject Public Key Info(SPKI)的哈希，具体生成方法可以参考Mozilla的文档：https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning#Extracting_the_Base64_encoded_public_key_information

fallback策略

虽然基于公钥的锁定不存在证书过期的问题，但依然需要fallback策略，因为可能存在私钥泄漏的情况下，这种情况下需要重新发布证书，公钥私钥都会改变。Android允许pin多个SPKI，只要符合一个就能正常通信，所以这里可以pin几个CA的根证书或者中间证书的SPKI，会损失一点安全性，但是为私钥泄漏的情况留下了操作空间。

结语

即使做了SSL Pinning，依然有HTTPS被劫持，内容被篡改的可能，比如对于证书锁定的方式，可以直接替换掉apk里的证书，再做重打包，对于公钥锁定的方式，可以通过hook RootTrustManager的方式直接绕过验证。
服务端需要在业务上对客户端请求做验证，只依靠机制上的安全是不够的，道高一尺魔高一丈，客户端和服务端应该互不信任，对于输入需要做足够的校验，这并不是一种overhead。

Telegram网络层源码分析

Shunix — Wed, 02 May 2018 11:43:18 GMT

最近看了一下Telegram网络层的源码，本来想网上找一下现成的结论，降低一点学习成本，但是并没有发现相关的资料。于是自己梳理了一下telegram是如何发送网络请求和响应回包的，这里做个总结。

连接的建立

先上一张图：

这张图描述了telegram客户端和server的连接时如何建立的。Java层的ConnectionsManager是一个线程安全的单例，其实只是个wrapper，真正的逻辑都是转交给C++层的ConnectionsManager类处理的。 C++层的ConnectionsManager对象，在TgNetWrapper.cpp中初始化，也同样是个单例。这里贴一下C++层ConnectionsManager类的init方法:

这里有两个关键的方法调用，一个是loadConfig()，一个是pthread_create()。顺着时间线往下看，loadConfig()调用了initDataCenter()方法，这个方法实现如下:

可以看到，主要是一些hardcode的IP和端口，其实在连接上第一个数据中心之后，客户端就会被分发到最优的数据中心接入，这里写这么多，可以看作一种fallback逻辑。
接下来使用了一个pthread_create的调用，新的线程中会执行ThreadProc()方法，这个方法会先调用sendPing()，实现如下：

这里调用了DataCenter的getPushConnection()和getGenericConnection()方法，这里把connection类型区分开的本意是下载，推送等使用不同的连接，这样可以防止一些耗时任务一直占用连接，同一个数据中心，可以给不同类型的连接分配不同的IP和端口，来提高网络连接的效率。
接下来是一个循环，循环中不断调用select()方法，来处理请求，这个方法的实现如下：

这里有一个epoll_wait()的调用，直觉上来说，这就是处理网络请求的核心，所以我们也从这里开始分析，先看一下这个epolFd上注册的fd:

这里分析一下，epolFd上注册的fd一共有两类：

socket。这里可以看到，socket连接在创建时，会向epoll注册自己，在关闭时会把自己从epoll的监视列表移除。而adjustWriteOp()方法是在socket发送数据时调用，我们知道，对于socket的send，只是把数据发送到了缓冲区，如果缓冲区满会触发EAGAIN，这个时候就要监听EPOLLOUT，表示缓冲区可写，adjustWriteOp()方法完成的就是这个操作。
用于事件通知的fd，这里有eventFd和pipeFd。这两个用于事件通知的fd不会同时使用，先初始化eventFd，pipeFd仅仅是在eventFd无法成功初始化时的备选方案。这两个fd具体用在哪里可以看下面的代码段。

wakeup()方法调用的地方在这里：

这个scheduleTask()方法是写得最耐人寻味的地方。我本来以为，这只是个网络请求的任务队列，后来查了一下这个方法的调用，发现这个队列的东西真是包罗万象，什么加载文件，加载配置，设置dns，设置语言等任务都放到了这个队列里，感觉上是一个jni层全局的调度器。而对于网络请求，都是放在requestQueue中，查看sendRequest()方法不难看出来，处理网络请求是在processRequestQueue()方法中进行的。
现在再来看select()方法，流程就清楚多了，epoll_wait会在以下几种情况下被唤醒：

socket连接有数据需要接收
socket缓冲区可写，上一次发送的数据没有完成
有任务在pendingTasks队列中

当线程被唤醒，不再阻塞之后，会首先去处理pendingTasks队列中的请求。然后调用epoll返回的EventObject对象的onEvent()方法依次处理，这个EventObject方法其实可以看作一个wrapper，会根据EventObjectType把逻辑分发到各个对象上，代码如下：

对于epoll，会用到的类型是EventObjectTypeConnection, EventObjectTypePipe, EventObjectTypeEvent.
完成EventObject的处理之后，接下来会关闭超时连接，这里的超时时间是12秒，然后要处理长连接的心跳。这里对于长连接心跳的处理如下：

关闭超时的长连接。这里对于超时的判定有两个条件，一是发送心跳包没有收到回包，已经过去了30s，二是距离上次发送心跳包时间已经过了190s。
判断当前时间距离上一次发送心跳包是否已经超过了180s，如果是的话，则发送长连接心跳包。这里可以得出结论，Telegram的长连接心跳周期是3分钟。
接下的处理非常良心，Telegram在检测到当前队列没有上传下载任务和向server请求盐值的任务时，会关闭和数据中心的socket连接。这里有一个阈值是10s，可以认为，如果把应用切到后台，在完成当前队列里的上传和下载请求10s后，Telegram就会关闭长连接，停止发心跳。这个操作非常省电，反观国内大把app，各种黑科技保活。
那么有一个问题，Telegram是如何保证休眠后还能接收到消息呢？答案是GCM，从AndroidManifest.xml里很容易找到GCM对应service的实现类：

这里的ConnectionsManager.getInstance().resumeNetworkMaybe()就是尝试重新恢复长连接的操作，逻辑很简单，就不再赘述。
最后一步，对于和DataCenter的普通连接，也发送心跳保活，这里的心跳周期是19s，然后每小时更新一次DataCenter的配置。再调用processRequestQueue()方法开始处理请求队列中的任务。
这里整理了一个比较直观的流程图，说明了发起请求的过程。

Telegram网络模块的分析就到这里了。

Android N多窗口适配

Shunix — Mon, 09 Apr 2018 10:32:39 GMT

前言

从Android 7.0开始，系统就开始支持多窗口模式，对于多窗口模式的适配，主要是两方面，UI适配和生命周期的调整，适配的工作量因App而异，下面就从几个方面来谈谈多窗口模式的适配。

多窗口模式规则

这里要注意，多窗口模式分为两种，split-screen模式和freeform模式，前者是单纯的屏幕一分为二，而后者允许用户自由调整两个activity的大小。根据官方文档的说法，所有Android N的设备都是支持split-screen模式的，而freeform模式由厂商决定是否开启，一般屏幕比较大的设备都支持这个模式。
AndroidManifest.xml中的android:resizeableActivity属性和应用的targetSDK共同影响着应用在分屏模式下的行为，这里先讨论应用没有指定orientation的情况。如果应用的targetSDK是24及以上，那么android:resizeableActivity属性默认为true，应用默认支持多窗口模式，当然应用可以手动覆盖掉这个默认值。如果应用的targetSDK是23及其以下，那么要分为三种情况。一是这个属性没有被指定，那么在进入多窗口模式时，系统会强制缩放应用，并且弹出一个提示框，告诉用户当前应用在多窗口模式下可能表现异常；二是这个属性为false，那么这个应用无法进入多窗口模式，一定是以全屏状态启动的；三是这个属性被手动指定为true，那么应用将正常进入多窗口模式，并且不会有情况一中的提示框。
如果一个task栈中的根activity支持多窗口模式，那么这个栈中的所有activity都支持多窗口模式。这条规则就意味着，如果我们的应用launcher activity支持多窗口模式，那么所有可能由内部调用呼起的activity也必须适配多窗口模式。

orientation的影响

上一节只讨论了没有activity没有指定orientation的情况，其实orientation相关的属性，对应用在多窗口模式下的表现也有很大的影响。很多页面会指定android:screenOrientation属性来锁定屏幕方向，这个属性根据targetSDK的不同，在多窗口模式下会有截然不同的表现。如果targetSDK是23及以下，所有指定了这个属性的activity都不支持多窗口模式，只能以全屏状态启动。如果targetSDK是24及以上，那么即使指定了这个属性，也可以进入多窗口模式，但是在多窗口模式中，这个属性会被忽略。这里要注意的是，一旦进入了多窗口模式，那么在代码中就无法使用setRequestedOrientation() 来锁定屏幕方向了，无论targetSDK是什么版本都没有效果。
一些System UI相关的特性在多窗口模式下也是无效的，如果是在Manifest里配置的属性，可能还会影响应用无法进入多窗口模式，比如android:immersive，规则同android:screenOrientation。

多窗口模式的生命周期

多窗口模式的引入，并没有改变activity的生命周期，但是更强调了RESUMED状态和STARTED状态的区别。之前我对于STARTED状态的理解是，activity对用户可见，而RESUMED是获取了焦点。如果没有多窗口模式，那么这两个状态一般没有什么区别，但是在多窗口模式下，就必然会出现一个activity对用户可见，但是并没有获取焦点的情况。永远都只有一个activity会处于RESUMED状态，但是另一个activity即使只是处于STARTED状态，优先级还是比不可见的activity要高的。
当activity在多窗口模式和全屏状态下互相切换，或者freeform模式下被调整大小时，系统会给activity一个配置变化的通知，如果Manifest里没有监听对应的配置变化，那么activity就会被销毁重新创建，否则activity的onConfigurationChanged() 回调会被调用。

生命周期适配

生命周期适配主要是两方面，一是对于配置变化的处理，二是对于STARTED和RESUMED状态的处理。配置变化至少要监听如下四个：android:configChanges="screenSize|smallestScreenSize|screenLayout|orientation"，然后在onConfigurationChanged() 回调中，可以用isInMultiWindowMode() 方法来判断当前Activity是否处于多窗口模式，并作相应的处理。当用户在多窗口模式和全屏模式切换，或者调整窗口大小时，都会调用onConfigurationChanged()回调方法。如果是一些和用户有持续性交互的Activity，比如音频和视频等，那么要注意，开始和暂停播放要分别放在onStart() 和onStop() 回调中，而不是onResume() 和 onPause() 中。

UI适配

因为freeform模式的引入，activity可用的窗口大小可以以任意比例变化，这就要求我们的布局是响应式的，能够适应不同的屏幕大小和比例。总结了一下，主要有以下几条建议：

避免hard-code的宽高，如果不是ConstraintLayout的话，尽量用wrap_content和match_parent来描述宽高。
如果是LinearLayout，可以尝试设置layout_weight来自适应屏幕，但是这样会降低性能，系统在layout时需要更多的计算，最好用ConstraintLayout替代。
使用最小宽度描述符来提供不同的layout，比如可以提供一个layout-sw320dp来适配正常非多窗口模式下的情况，这里要注意一下适配规则，swdp指定的数字，是宽和高的最小值，叫smallest possible width更准确一点。如果提供了多个不同数值的swdp，系统会使用最接近，但是没有超过设备屏幕大小的那一个。freeform模式下调整窗口大小会触发配置变化，系统会在这个时候调整使用的layout。
尽量使用fragment来实现UI相关的逻辑，这样可以尽可能地避免重复代码，在适配多种屏幕大小时复用现有的逻辑。
可能被拉伸的图片使用nine-patch切图。
最后一条，尽量使用ConstraintLayout吧，这个Layout基本上可以实现所有用LinearLayout，RelativeLayout和FrameLayout实现的布局，而且有助于减少View的层级。因为ConstraintLayout本身的机制，写出来的布局基本上天然是响应式的，可以减少很多适配工作。

layout标签

针对多窗口模式，Android还提供了标签，这个标签提供了5个属性用来控制activity在多窗口模式下的表现。android:defaultWidth和android:defaultHeight用来指定在freeform模式下启动时的默认宽高，android:gravity用来指定在freeform模式下启动时activity的初始位置，android:minHeight和android:minWidth用来指定在多窗口模式下activity的最小宽高，如果用户手动调整分界线导致窗口大小小于这个数值，当在split-screen模式下，activity将被裁剪，canvas依然维持minWidth和minHeight的大小，如果在freeform模式下，那么activity是无法被缩放到minWidth和minHeight以下的，这两个属性在freeform模式下更符合字面意思。

多窗口模式下启动activity

多窗口模式下，activity可以被启动在另一个窗口，但是要同时加两个flag：

Intent intent = new Intent(this, ActivityB.class);
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
intent.setFlags(Intent.FLAG_ACTIVITY_LAUNCH_ADJACENT);
startActivity(intent);

这里一定要加FLAG_ACTIVITY_NEW_TASK，否则FLAG_ACTIVITY_LAUNCH_ADJACENT会被忽略。

适配验证

全屏模式下启动应用，然后切换到多窗口模式，看是否表现正常。
直接以多窗口模式启动应用，看是否表现正常。
多窗口模式下拖动分界线，应用不能崩溃，并且UI展示正常，这里还要关注UI重绘是否存在性能问题。
在指定了layout标签的时候，观察拖动分界线时的表现是否符合预期。
如果是和用户有持续交互的应用，比如音视频播放，浏览器等，检查多窗口模式下状态是否正常。
快速拖动分界线，检查是否存在内存泄漏。

CVE-2017-13156漏洞分析（中）

Shunix — Thu, 28 Dec 2017 11:35:58 GMT

承接上篇，本篇主要介绍一下Android的签名机制，并从原理上分析一下为什么使用APK Signature Scheme v2签名的应用在Android 7.0以上不受漏洞影响。Android提供了两种签名方式，一种是v1的基于JAR签名的方式，另一种就是APK Signature Scheme v2。

签名验证时机

首先看一下PackageManagerService的代码，看看是什么时候进行签名验证的。

PMS的installPackageLI方法会构造一个PackageParser对象，并调用collectCertificates方法来验证签名。

这里可以看到，首先要对apk文件的entry做遍历，如果遇到entry是目录，或者是META-INF文件名，或者是AndroidManifest.xml则跳过，否则把entry加入一个List，这个List中的每一个entry将在下一步进行签名验证。验证签名的过程后面会说，这一节只是说明，在apk安装的时候，PMS会进行签名验证。

V1签名

Android官方文档有说，在APK Signature Scheme v2签名之前，签名使用的是基于JAR签名的方式。关于JAR签名，oracle的官方文档在这里。官方文档有点冗长，这里用一个例子来说明一下这种签名。
签名完的JAR包会多出一个目录，META-INF，里面会多出来这么几个文件:

MANIFEST.MF，这个文件只会有一个，是zip entry的清单文件。
*.SF，这个后缀结尾的文件，命名可以任意，因为JAR允许多重签名，所以这个类型的文件可能存在多个，每一个SF文件对应一个签名者。
*.RSA，这个后缀结尾的文件，命名也是任意的，但是必须和SF文件一一对应，每一个RSA文件也对应着一个签名者。

先看一下前两个文件的内容：

截得不全，但是这一部分已经可以足够分析这两个文件的作用了。对比两个文件的头部，我们发现，SF文件比MF文件要多两个属性，SHA1-Digest-Manifest-Main-Attributes和SHA1-Digest-Manifest
，而其他内容格式是一致的。这里看一下jarsigner的源码可以很方便地理解这两个文件内容。

这是main方法，可以看到，是按顺序写入MANIFEST.MF, CERT.SF和CERT.RSA的，先看看写入MANIFEST.MF的方法addDigestsToManifest()。

这个方法会遍历当前zip包内所有entry，并针对每一项生成一个SHA1的摘要，和文件名一起写入到MANIFEST.MF中，META-INF下的文件是例外的，不会生成摘要信息。MANIFEST.MF保存了每一个zip entry Base64编码后的SHA1摘要。
再看看写入CERT.SF的方法writeSignatureFile()

CERT.SF文件存储的是MANIFEST.SF文件的摘要信息，首先看头部SHA1-Digest-Manifest，看代码很容易知道，这是MANIFEST.SF整个文件的SHA1摘要，接下来的循环，把原本MANIFEST.MF里每一项再做一次SHA1摘要，以同样的格式写入CERT.SF。所以表面上看起来CERT.SF和MANIFEST.SF格式差不多，但其实在证书校验中的作用完全不同。
最后来看一下CERT.RSA文件，这是个二进制文件，所以我们需要借助OpenSSL来解析。

显然，这包含了X509的证书，有公钥，加密算法，有效期，签发者等信息。让我们看看生成这个文件的代码：

writeSignatureBlock方法会将用私钥加密后的CERT.SF，以及包含了公钥的数字证书一起写入到CERT.RSA文件，这个文件符合PKCS7格式。

V1签名的验证

有了上面的背景知识，再来看Android对于apk对V1签名的验证，就不难理解了，贴代码：

中间过程过于冗长，这里直接给结论，Android对于V1签名的验证，主要分以下几个步骤：

对apk文件中每个file entry做SHA1摘要，Base64编码后与MANIFEST.MF中内容比对。
对RSA和SF文件进行校验，因为RSA文件中，有私钥加密后的签名，还有公钥，所以可以根据公钥解签名，这里应该能得到CERT.SF的SHA1摘要，跟当前CERT.SF做比较就可以知道CERT.SF有没有被篡改。
比对MANIFEST.MF整个文件的SHA1摘要，看是否和CERT.SF头部记录的一致，然后再逐条比较MANIFEST.MF数据项的摘要是否和CERT.SF对应条目一致。这样可以确定MANIFEST.MF有没有被篡改。

这里可以看出，基于JAR签名的方案，是有缺陷的，V1签名方案是对zip文件的entry做校验，并没有校验整个apk是否被篡改。所以就有了很多利用这一点的黑科技，比如zipalign对齐，美团的多渠道打包方案，在apk使用V1签名完后还是可以做一些修改，而不影响签名的验证。CVE-2017-13156漏洞也是一样，因为并没有修改原来apk文件zip entry的数据，所以签名验证是可以通过的。

V2签名

因为V1签名有以上的缺点，所以Android在7.0之后加入了对V2签名支持。SDK目录下的apksigner工具可以完成对APK的V2签名。V2签名并不是apk文件中的一个entry，而是在Central Directory之前的一段block，这里借鉴一下Android官方文档的图片：

可以很明显看出，签名之后，多出了红色的部分，紧邻Central Directory之前。从源码来看一下这个块的格式：

签名块分为以下几个部分：

uint64类型，8个字节，表示整个block长度
多个ID/Value的键值对
和第一个字段一样的，8字节的block长度
uint128类型，16字节的magic number，内容为“APK Sig Block 42”
V2签名block的ID为0x7109871a，这段代码只从键值对pairs中读取V2签名块的内容，其余部分不作处理。
V2签名块的内容主要包含了签名，公钥和证书，生成V2签名块的代码比较冗长，可以查看源码，这里总结了一下步骤，先来看一张图：

这里把整个APK文件分为了4个部分，APK Signing Block是对1，3，4的校验，并不包括本身。校验值的计算步骤如下：
把1，3，4分别分成1M大小的连续数据块
对每一块分别计算摘要信息，摘要的计算方法是把0xa5，数据块大小（小端字节序）和数据块内容拼接起来根据传入的算法做摘要。
把0xa5，数据块数量和数据块的摘要拼接，再做一次摘要
最后计算出的摘要私钥加密后即为签名

显然可以看出，整个过程是很容易并行的，因为数据块之前没有关联性，V2签名同时保护了zip entry和Central Directory，任何一个字节的改变都将导致签名校验失败。因此CVE-2017-13156漏洞这种在头部拼接dex文件的方式无法通过签名验证。

V2签名的验证

这里可以看一下PackageParser.collectCertificates方法在Android 7.0以上的实现：

可以看到，PMS会先尝试验证V2版本的签名，只有V2版本签名找不到时，才会降级为验证V1版本的签名，因此同时使用了V1和V2签名的APK，是无法通过降级策略绕过V2签名的校验的。
这里再看一下校验V2签名的代码

findSignature方法通过找到EoCD的位置来确定Central Directory的位置，从而找到签名块的位置，再通过之前贴过的findApkSignatureSchemeV2Block方法找到V2签名块，并获取其中的签名，证书等信息。verify方法则是完成真正的签名校验，签名校验过程无非是非对称解密那一套，这里不再赘述。
V2签名对APK完整性提供了更全面的保证，因此对于APK同时使用V1和V2签名可以在保证兼容性的同时提高安全性。
这里多说两句，美团之前的多渠道打包方案在V2签名机制下也失效了，对于V2的多渠道打包，只能在签名块中写入新的ID/Value键值对来实现，因为目前对于V2签名的校验，只识别了ID为0x7109871a下的value，不认识的ID一律不作处理。

CVE-2017-13156漏洞分析（上）

Shunix — Mon, 18 Dec 2017 02:06:26 GMT

前言

CVE-2017-13156是今年Android爆出的最为严重的一个漏洞，这个漏洞允许攻击者绕过Android系统V1的签名，用篡改过的apk覆盖原有的应用，攻击者的代码可以访问原应用所有的数据。影响范围是Android 5.0+。这个漏洞的本质原因是ART允许直接运行一个dex，同时也允许运行一个里面包含dex的zip文件。而因为dex文件格式和zip文件格式的问题，一个文件可以同时是合法的zip文件和合法的dex文件。正是因为这种二义性，这个漏洞也被称作Janus漏洞，Janus是罗马神话中的双面神，具有前后两个面孔。对于特殊修改过的apk文件，PackageManagerService把它当作合法的apk安装，而ART把它视作合法的dex执行，这就是一个文件的两个视角。github上已经有人放出了这个漏洞的PoC，代码虽然很简单，但是看懂需要一点背景知识，下面就从zip和dex的文件结构上来解释这段代码。

Zip文件结构

Zip文件最重要的一个部分就是末尾的Central Directory，这个部分可以理解为Zip文件真正的文件头，解析zip文件都是从这里开始解析的，它包含了zip文件每一个entry的摘要信息。这个部分的结构如下：

这里很容易看出来，Central Directory里有多个File header，而每一个File data前面也有一个local file header，前者是后者的加强版，包含了更详细的数据。File header结构如下,markdown制表比较麻烦，这里从维基百科上截了一张图：

这里需要注意几个重要的字段，file header总是以magic number 0x02014b50开头，file header的第42~46字节是对应的local file header的偏移，解析zip文件的时候就是根据这个字段找到每一个文件entry的。
End of central directory record的结构很固定，图片同样取自维基：

EOCD是以magic number 0x06054b50开头的一个数据块，其中第12~16字节包含了central directory的长度，16~20字节包含了central directory起始位置的绝对偏移量，为了理解后续的内容，请特别留意这三个字段。
看完上面几张图，我们可以很容易地得出zip文件的解析流程:

根据magic number 0x06054b50找到End of central directory record
根据End of central directory record中第16~20字节找到central directory的起始位置
以magic number 0x02014b50为标记位，遍历central directory中每一个file header
根据file header中的元数据找到local file header的位置
根据local file header的元数据解析file data

zip的这个特性使得解压工具在不需要读取完整文件内容的情况下就可以展示整个压缩包的结构。zip文件实际上的文件头是在尾部的，因此头部可以任意拼接数据，只要修改好相应的偏移量，这个文件还是一个合法的zip文件，比如自解压程序的实现，就是在头部拼上了exe文件。zip格式只要求了应用必须从central directory开始解析文件，但是并没有要求检查整个文件是否以0x02014b50开头，一般情况下，这并不会有什么问题，但是结合ART的机制和dex的文件结构，就导致了Janus漏洞。

Dex文件结构

Dex文件结构没必要了解得那么细致，跟本文有关的只有一个文件头，这里我从Android官网找了一张图，截得不全，但是对于本文足够了:

dex文件总是以magic number DEX_FILE_MAGIC开头，这个值是**{ 0x64 0x65 0x78 0x0a 0x30 0x33 0x38 0x00 }，写成ASCII的表示就是我们平时看到的"dex\n038\0"**。我们只需要关注dex文件头的前4个字段，第一个是magic number，占8个字节，第二个是dex的adler32校验码，占4个字节，第三个是SHA-1的签名，占20个字节，第四个字段是dex文件的总长度，占4个字节。理论上来说，同时修改这几个字段，我们就可以保持一个dex文件是合法的。

PoC

好了，有了这些前置知识，就可以来看一下脚本了，脚本我加好了注释，应该很容易懂。

官方修复

PackageManagerService安装应用的时候，会使用PackageParser这个类去解析apk包，而Android 5.0以上的PackageParser解析apk的时候，使用的是StrictJarFile类，这个类其实是一个jni的wrapper，真正的实现要看zip_archive.cc.我们先来看一下Google对于这个漏洞的修复：

Google在解析zip文件的Central Directory的时候加上了对文件头的判断，如果不是以特定的magic number开头，则返回错误。而在这之前，zip_archive.cc是直接解析Central Directory的，并没有验证文件头部几个字节，使用PoC脚本修改过的apk文件可以顺利完成解析，覆盖掉原有应用。

后记

后面还会有两篇，分别分析ART为什么会先执行修改后拼在头部的dex文件和Android V2签名为什么不受这个漏洞的影响。时间关系，先写了这一篇。

SharedPreferences源码分析

Shunix — Tue, 14 Nov 2017 08:07:56 GMT

前言

SharedPreferences作为Android应用配置项的存储，给上层提供了非常方便的接口，这篇Post将从源码层面分析SharedPreferences实现的细节。

获取SharedPreferences

获取SharedPreferences实例是通过ContextImpl.getSharedPreferences(String name, int mode)方法来完成的。

这里的sSharedPrefs是ContextImpl的静态成员，类型为ArrayMap>，从这个ArrayMap里，我们可以通过包名获取另一个ArrayMap packagePrefs，其中包含文件名到SharedPreferencesImpl的映射。这里我初看的时候不太理解，为什么要两级映射。后来想了一下，应该是针对sharedUserId的情况，这种情况下，同一个进程会有不同的Context和包名，个人见解，如果不对，欢迎指正。
这里要注意如下几点：

ContextImpl对SharedPreferencesImpl对象是做了缓存的，因为是静态成员，所以同一进程内，无论调用多少次getSharedPreferences方法，返回的对象都是同一个。
如果指定了MODE_MULTI_PROCESS的flag，那么执行startReloadIfChangedUnexpectedly方法，这个方法的具体内容会在后面分析，这个方法的实现也算是SharedPreferences的一大黑点。

SharedPreferencesImpl初始化

ContextImpl如果发现请求的SharedPrefernces不在缓存中，就会创建新的SharedPreferencesImpl对象，并加入缓存。

SharedPreferences从文件加载到磁盘的流程如下：

把mLoaded置为false，这个变量用来标识文件是否已经完成了加载，对这个变量的访问都是上锁的，一是为了保证可见性，而是为了保证同步。然后新创建一个线程，真正执行从磁盘加载的操作。
如果检测到备份文件存在，说明当前文件mFile是有问题的，直接删除，并用备份文件覆盖当前文件。
从XML文件读出键值对，保存在mMap数组，并记录下当前文件的大小和修改时间戳到mStatSize和mStatTimestamp。

初始化过程就是这样，这段代码第24-26行我个人认为是多余的，只有loadFromDiskLocked()方法本身会把mLoaded置为true，但是这个方法本身是用this加锁的，理论上是不会出现，进了这个方法，mLoaded为true的情况。

SharedPreferences读取

读取相关的代码相对简单，取一段作为样例：

awaitLoadedLocked在每次取数据之前都会调用，如果mLoaded为false，说明没有加载完，那么挂起当前线程，等待加载完后统一唤醒。因为用了wait/notify，所以awaitLoadedLocked调用前必须获取this的锁。
取数据就是从mMap中根据key取出需要的数据，如果是getAll()的话，这里返回的是mMap的副本，以免对返回数据的修改影响了mMap的值。这里mMap是如何保证和磁盘上文件同步的，看完后面SharedPreferences的写入就会明白。

SharedPreferences写入

SharedPreferences的写入是整个SharedPreferences源码中最复杂的一块。但只是相对而言，其实仔细看看还是很好理解的。
SharedPreferences的所有写入操作，都是通过一个内部类SharedPreferencesImpl.EditorImpl来实现的。源码里的putXX方法我只摘了一个出来，多余的去掉了：

我们知道，写入流程，一般都是putXX->commit/apply，我们就按这个流程入手，来看看到底写入SharedPreferences的时候执行了哪些操作。这里可以看到，putXX实际上执行的操作，就是把key/value对放到了mModified里面。真正的写入过程，先以commit()方法为例看看。
这里又要引入另一个内部类MemoryCommitResult

这个内部类表示的是把修改提交到内存的结果。commit()方法的实现，先调用了commitToMemory()方法，获取了返回的MemoryCommitResult之后，再把返回结果加入磁盘写入队列，并在当前线程等待写入操作完成，最后通知所有的监听器，写入完成。

提交到内存

**commitToMemory()**的实现比较繁琐，这里分步讲解一下：

先检查mDiskWritesInFlight变量，看有没有正在写入，或者等待写入的数据，如果有的话，这里要做一次深拷贝。这里第60行我初看也觉得很奇怪，但是结合后面一起看，就能理解了。这里注意到，第62行是直接把mMap赋值给了mapToWriteToDisk，这里是浅拷贝，也就是说，修改mMap的值，同样会影响mapToWriteToDisk，而后者是被加入磁盘写入队列，正在被写入，或者将要被写入到磁盘的Map，这种影响显然是我们不希望发生的，因为在写入磁盘时，获取的锁并不是this，如果mapToWriteToDisk在这时被修改，可能出现异常。所以这里深拷贝之后，可以保证mapToWriteToDisk指向的，永远是那个时刻的Map。
增加mDiskWritesInFlight，标记要写入磁盘的任务增加了一个。
检查mClear，看看是否需要清空当前SharedPreferences。
81-106行合并了mModified到mMap，这里需要注意一个很tricky的地方，第87行的判断，其实remove()方法的实现，就是把value设为EditorImpl本身，效果等同于把某一个key对应的value设为null。
最后把mModified清空，因为已经被合并到了mMap。

写入磁盘

写入磁盘相关的代码如下：

enqueueDiskWrite方法接收两个参数，第一个是上一步返回的MemoryCommitResult对象，第二个参数是一个Runnable对象，如果是从commit()调用的，第二个参数应该为空。这里的QueuedWork是一个工具类，会创建一个当前进程共享的单线程执行器，其实相当于一个队列，按照入队列顺序执行写入操作。注意，如果是commit()调用，这里并不会用到QueuedWork的线程池，而是直接在当前线程完成写词盘操作。写入操作的具体实现在writeToFile方法。

第77到96行，重命名当前文件作为备份文件，用于在写入错误的时候进行回滚。如果备份文件已经存在，那么说明当前文件是有问题的，直接删除当前文件。
把MemoryCommitResult.mapToWriteToDisk写入到磁盘，并执行fsync操作，然后根据mMode设置文件权限。
记录下当前文件的大小和修改时间戳到mStatSize和mStatTimestamp。
删除备份文件，并返回结果给MemoryCommitResult，这个操作会解除commit()对CountDownLatch的等待。
如果上述操作失败，则删除未完成写入的文件。

异步写入

现在再来看看**apply()**方法的实现：

把apply()和commit()结合起来看，commit()直接在当前线程执行了await操作，而apply()是写了一个Runnable，这个awaitCommit最后会在哪个线程执行呢？这里就要看看QueuedWork的源码：

从代码里可以看到，这里把awaitCommit加入到QueuedWork.sPendingWorkFinishers，并不会马上执行，只会在waitToFinish()中执行，而这个方法的调用时机，也只有Activity的onPause()中，BroadcastReceiver的onReceive()调用后等几个时机，只是为了保证异步任务不丢失而做的fallback逻辑。真正的写入还是调用writeToFile()方法，任务会被分发给QueuedWork提供的单线程线程池执行。

多进程问题

最后来说一下SharedPreferences的一个最大的坑，多进程下的问题。先来看一个flag的定义：

Context.MODE_MULTI_PROCESS
This constant was deprecated in API level 23. MODE_MULTI_PROCESS does not work reliably in some versions of Android, and furthermore does not provide any mechanism for reconciling concurrent modifications across processes. Applications should not attempt to use it. Instead, they should use an explicit cross-process data management approach such as ContentProvider.

看官方文档，他们还是知道这里的实现是有问题的。我们回溯到代码，看一下对于这个flag的处理，前面我们看到过，ContextImpl如果发现了这个flag，就会调用**SharedPreferencesImpl.startReloadIfChangedUnexpectedly()**方法，这个方法实现如下：

这个方法做的，仅仅是在文件有变化的时候，重新加载了一遍。首先，这个操作不是原子性的，并没有用flock锁住文件，因为mFile和mBackupFile的关系，一个进程在写，而另一个进程在读的时候，就会造成写入的数据丢失。第二，这个判断文件是否有变化的条件也是有问题的，只要检测到mDiskWritesInFlight大于0就认为是自己修改了文件时间戳，这是不严谨的，假如当前进程的写任务只是刚刚写到了内存，而另一个进程修改了文件，此时mDiskWritesInFlight是大于0的，但是文件确实发生了本进程不知道的修改，另一个进程写入的数据还是读不到。所以官方很良心地废弃了这个Flag，转而推荐用ContentProvider实现跨进程数据共享。

TLS握手过程

Shunix — Wed, 13 Sep 2017 13:30:23 GMT

最近和朋友吃饭的时候，聊到了HTTPS，HTTPS其实就是基于TLS建立了安全信道的HTTP协议。所以可以说，HTTPS最重要的就是TLS的握手过程。这篇post整理了一下TLS的握手过程。

前置知识

这里要先讲几个概念，在后面对于TLS握手过程的描述中会用到这几个概念。

HTTPS TLS和SSL的关系

SSL是90年代Netscape弄出来的一套东西，为的是解决HTTP协议明文传输数据的问题。后来SSL慢慢成了事实上的标准，于是IETF就把SSL标准化了，名字叫做TLS，TLS 1.0其实就是SSL 3.1。所以SSL和TLS经常被放在一起写成SSL/TLS，因为这两个名词在现在其实就是同一个东西。HTTPS是使用TLS的HTTP协议。

证书及信任链

我们知道，HTTPS的网站都有一个自己的证书，用于表明自己的身份。证书本质上是为了让公钥能可信的传输。公钥是放在证书里面的，如果证书可信，那么公钥就也是可信的。那为什么一个公钥是可信的呢？这就要说到信任链和CA。CA指的是Certificate Authority，CA都是权威机构，他们的证书叫做根证书，这些根证书被操作系统信任，根证书信任的证书也是可信的。因此权威机构颁发的证书都能被操作系统信任，这就组成了信任链。

TLS握手过程

这里借用了一张CloudFlare的图，这张图不是很详细，但我个人觉得这个粒度应该是最合适的，主要部分都有描述，又不至于让人过于纠结细节。

其实TLS提供了多种密钥交换算法，这里以RSA为例，分步讲解以下TLS的握手过程。

客户端初始请求

客户端向服务器发出请求，会带上以下信息：

一个客户端生成的随机数
支持的加密方式，即图中的Cipher Suite
支持SSL/TLS协议的版本号
Session ID，如果是之前断开的会话，会带上Session ID用来恢复会话。
签名使用的哈希算法

服务器回应

服务器响应客户端的请求，如果上一步带上了Session ID，则直接恢复会话，否则带上以下信息给客户端：

选择SSL/TLS协议版本号
选择加密方式
一个服务器生成的随机数
服务器证书

客户端会在这里校验服务器证书的合法性，包括检测证书有效时间，以及证书中域名与当前会话域名是否匹配，并沿着信任链查找顶层证书颁发者是否是操作系统信任的CA机构，这里验证信任链的时候，需要用上一级证书的公钥对证书里的签名进行解密，还原对应的摘要值，再使用证书信息计算证书的摘要值，最后通过对比两个摘要值是否相等，如果不相等则认为该证书不可信，如果相等则认为该级证书链正确，以此类推对整个证书链进行校验。

客户端回应

客户端校验服务器证书的合法性，生成premaster secret，向服务器发送以下信息：

用服务器证书取出的公钥加密后的premaster secret，这里的premaster secret其实是另一个随机数
加密约定改变通知，通知服务器，以后的通信都适用协商好的加密方法和密钥进行加密
客户端握手结束通知。这个报文也是验证消息，是前面发送的所有内容的哈希值，用来供服务器校验。

服务器最后确认

这是握手过程的最后一步，服务器会把以下信息发送给客户端：

加密约定改变通知，通知客户端，以后的通信都适用协商好的加密方法和密钥进行加密
服务器握手结束通知，该报文也作为校验消息，供客户端验证。

到这个时候，客户端和服务器同时拥有了3个随机数，使用这三个随机数生成的密钥，将被用于后续通信的对称加密。也就是说，只有握手过程才有非对称加密，非对称加密是比较慢的，因此只用于建立安全的信道，Payload的传输都是对称加密的，对称加密的速度和资源占用比非对称加密都要好，因此对性能的影响是很小的。

Port leveldb to Android

Shunix — Fri, 07 Jul 2017 09:39:26 GMT

As leveldb has already implemented platform-dependent interfaces, porting leveldb is pretty simple. Cross compile the source code on Linux or build with NDK are both OK. Here's my NDK build script. It compiles with NDK r13b and leveldb 1.20.

You can get the full source code at leveldb-ndk

Steam升级指南

Shunix — Sat, 22 Apr 2017 18:38:36 GMT

前言

混了这么久的steam，帐号等级一直很低，本来只是准备升一下等级的，没想到就入了挂卡的坑，这里写一篇攻略吧，讲讲关于steam升级的一切。

背景知识

什么是喜加一？

本意是说，买了也不玩，只是让库存游戏数量加一的行为。后来喜加一游戏也用来指那些质量低下，但是很便宜的游戏，通常来说，这些游戏几乎没有可玩性，唯一的优点就是便宜。像下面这张图里，这些被我隐藏掉的，都是喜加一游戏。

什么是steam集换式卡牌？

虽然叫集换式卡牌，但是并不能拿来玩卡牌游戏，唯一的作用就是拿来合成徽章，就像下面这两张图一样，合成完的徽章会出现在个人资料页。

每个游戏会掉落总数一半左右的卡牌，举个例子，Don't Starve一共有5张卡牌，那么通过游戏可以免费掉落的就是3张（向上取整），掉落的卡牌是会重复的，集齐一整套卡牌就可以合成徽章，自己没有的卡牌可以通过和其他玩家交换或者直接购买得到。徽章也是可以升级的，最高能升到5级。
因为steam有2小时内游戏时间可以退款的规定，所以大部分卡牌都要2小时之后才会掉落（据说从来没退过款的玩家没有这个限制，不确定这个说法的真实性）。平均下来每半小时会掉落一张卡牌。
卡牌分为普通边框和闪亮边框两种，闪卡价格通常都是普卡的好几倍，可以用来合成闪亮徽章，闪亮徽章通常会更好看一点。因为闪卡的稀缺性，所以价格都标的很随性，部分好看一点的闪卡，价格是比较离谱的。一级的闪亮徽章可能比五级的普通徽章还要贵。

什么是补充包？

补充包是一个包含三张卡牌的包，当一个游戏没有可以掉落的卡牌之后，就有了获取补充包的资格，只要每周保持登录，就有可能获取随机掉落的补充包，补充包是获取闪卡的主要途径。

什么是慈善包？

大部分人在steam买游戏都是等到打折才买，其实还有另一种获取低价游戏的途径，就是慈善包。慈善包会把一些游戏打成几个包，分为基础包，均价包和全价包，付对应的价钱就能获得包内的游戏，收入的一部分会拿去做慈善。基础包一般是最低1美元，均价包就是所有购买了该慈善包的用户所支付金额的均价，这个会随着时间上涨，所以要买的话尽快出手，全价包就没有上限了，想给多少都行。

Steam等级

Steam等级有什么作用？

首先，个人资料页展示的好友只有6个，这个顺序就是按等级排的，等级高的话，会排在别人资料页的前面。然后每升一级都会增加5个好友位。补充包的掉落率也会随着等级的提高而增加。10级+20%的掉落率，20级+40%的掉落率，30级+60%的掉落率，依此类推。每升10级还会送一个展柜，可以用来放自定义的内容，像下面这样：

简单来说，就是等级越高越方便装逼。

如何提升等级？

目前只能通过买游戏或者合成徽章来获取经验，买游戏能拿到的经验太少了，主要途径还是合徽章。每次合成或者升级徽章，会获得100经验，从0~10级每级要100经验，10~20级每级要200经验，20~30级每级要300经验，依此类推。我个人觉得，30级是一个性价比比较高的等级，解锁了3个展柜，400个好友位，基本上也够用了。

如何高效经济地提升等级？

终于切入正题了，steam上的玩家，土豪毕竟是少数。大部分都希望钱花在买游戏上，等级这种东西，最好少花点钱。当然，我平时工作也很忙，不可能像某些学生党一样，整天混迹在社区市场，通过低买高卖来赚差价。所以这里总结了一下，怎么样才能相对高效经济地提升等级。

首先是多买喜加一游戏，当然，要买能掉卡的那种，一般来说，steam特惠里面，2块钱以下的都可以直接买了，然后就是多关注慈善包，如果只是为了挂卡的话，都买基础包就够了，平摊下来，每个游戏也就2块钱不到点。这里推荐几个方便买喜加一挂卡游戏的慈善包网站：
Humble Bundle，大名鼎鼎的Humble Bundle，月包质量挺高的，不止可以买喜加一
IndieGala，这个建议直接去淘宝买欢乐时光包，相当于团购，要便宜很多
驰游，国内网站，爱卡包游戏单价特别便宜，大约几毛钱一个，但是除了便宜也没别的优点了
然后就是关于合成徽章的策略了。每个徽章合成都是100经验，但是所需要的成本是大不相同的，一些好看的徽章，或者热门游戏的徽章，合成所需要的卡片就会很高，几块钱一张的卡片也是有的。一些卖相不好的徽章，合成所需要的卡片就会很便宜，七八分钱的也有很多。既然我们的目的只是要升级，那就不用管徽章好不好看了。这里建议，掉落的卡片，售价高于0.5元的，直接上架卖掉，挂市场价就行，很快能卖掉。低于0.5元的，可以考虑留下合成徽章。最后平均算下来，不算买游戏的钱，每100经验的成本应该是在1块钱左右的，升到30级大概只需要60块钱，也就是一个游戏的价钱。
合成徽章会得到一些副产品，主要是游戏优惠券，资料页背景和表情。我的建议是，优惠券如果有折扣力度很大，折完一两块钱的，可以买来继续挂卡，资料页背景，好看的自己留着，不好看的直接分解成宝珠，表情一律分解成宝珠。宝珠可以拿来做补充包，补充包可以卖掉或者自己开闪卡。

关于挂卡

之前有说到过，集换式卡牌是需要一定的游戏时间才能掉落的，买了那么多喜加一，不可能真的都自己玩够时常吧。这个时候，就需要一个开源挂卡工具：ASF，运行需要最新版本的.NET Framework。在自己电脑上挂太麻烦了，推荐搞个Linux的VPS，然后装个mono就可以24小时挂卡了。教程在这里。如果遇到频繁需要输入steam二次验证码的问题，可以看看这个。ASF支持离线挂机，这一点还是非常方便的，可以避免别人在你挂机的时候误认为你在线，小窗不回的误会。

结语

最后给个我的资料页链接，欢迎大家加好友。
https://steamcommunity.com/id/rayewang

Blog Migration Notes

Shunix — Sun, 09 Apr 2017 13:09:18 GMT

My SSL certificate expired at the end of last month. And I lost the private key of my EC2 instance by chance. As I didn't want renew the SSL certificate and my amazon account is running out of credit, I decide to migrate my blog to vultr. I keep a migration notes here, so the migration will be more efficient next time.

Step 1: Back up blog data.
As my blog is backed by Ghost, I exported blog data in its control panel and got a json file.
Step 2: Install nodejs and npm on new VPS.
Install nodejs and npm with the package manager of your distribution. Take Ubuntu for example.
$ sudo apt-get install nodejs
$ sudo apt-get install npm
On some versions of Debian/Ubuntu, nodejs-legacy package is required. It provides necessary symbolic links.
$ sudo apt-get install nodejs-legacy
Step 3: Install Ghost.
Download Ghost and unzip it.
$ curl -L https://ghost.org/zip/ghost-latest.zip -o ghost.zip
$ unzip -uo ghost.zip -d /var/www/ghost
Now install dependency for Ghost.
$ cd /var/www/ghost && npm install --production
Step 4: Configure Ghost.
Create config.js.
$ cd /var/www/ghost && cp config.example.js config.js
Substitute domain name in production section with your own. If you don't need mail service, leave the mail brackets blank. If you do, Mailgun is recommended.
Step 5: Make Ghost run.
$ npm start --production works fine surely. But if you log out from SSH, ghost will stop running. forever give us a way to run Ghost as a service.
$ npm install forever -g
$ NODE_ENV=production forever start index.js
Step 6: Obtain a SSL certificate.
Let's Encrypt provides free SSL certificate. Detailed information can be found at https://letsencrypt.org/.
Since Let's Encrypt certificate only last for 90 days, I add a line to crontab to auto renew certificate.
0 6 * * 1 certbot renew
Step 7: Reverse proxy with nginx.
By default, Ghost runs on port 2368. It's not recommend to run Ghost directly on port 80 for security concerns. We should run Ghost with a web server and proxy the access of port 80 to port 2368. I prefer nginx.
Create a configuration file for ghost and create a symbolic link.
$ touch /etc/nginx/sites-available/ghost.conf
$ sudo ln -s /etc/nginx/sites-available/ghost.conf /etc/nginx/sites-enabled/ghost.conf
Here's my ghost.conf, it contains SSL configuration.

server {
    listen 80;
    server_name shunix.com;

    location / {
        return 301 https://$server_name$request_uri;
    }
}

server {
    server_name www.shunix.com;
    return 301 $scheme://shunix.com$request_uri;
}

server {
     listen 443 ssl;
     server_name shunix.com;

     root /var/www/ghost;
     index index.html index.htm;
     client_max_body_size 10G;

     location / {
         proxy_pass http://localhost:2368;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header Host $http_host;
         proxy_set_header X-Forwarded-Proto $scheme;
         proxy_buffering off;
     }
     ssl on;
     ssl_certificate /etc/letsencrypt/live/shunix.com/fullchain.pem;
     ssl_certificate_key /etc/letsencrypt/live/shunix.com/privkey.pem;
     ssl_prefer_server_ciphers On;
     ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
     ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;
 }

Step 8: Change A record to point to new IP address.
Step 9: Setup account and import data.

Till now, we have complete the migration, the new blog should be online.

Activity Leak Detection

Shunix — Tue, 17 Jan 2017 13:20:23 GMT

Prior Knowledge

Reference and ReferenceQueue

Begin with Java 1.2, the java.lang.ref package give us limited degree of interaction with garbage collector. The subclasses of Reference and ReferenceQueue are quite useful if we wanna do something with garbage collection.
The constructor of Reference takes a referent and a ReferenceQueue as parameters.

Reference(T r, ReferenceQueue q) {
    referent = r;
    queue = q;
}

We can regard ReferenceQueue as a callback of garbage collector. At some point, garbage collector will enqueue the reference. For different reference types, the time is different.
Three different type of references exist, each being weaker than the preceding one: SoftReference, WeakReference and PhantomReference. "Weakness" here means that less restrictions are being imposed on the garbage collector as to when it is allowed to actually garbage-collect the referenced object.
Garbage collector will not clear the referent of SoftReference until the runtime must reclaim memory to satisfy an allocation. But it's not recommended using it for caching as it's inefficient.
WeakReference is commonly used for "canonical mappings". WeakHashMap is a typical case. Unlike SoftReference, WeakReference will be cleared and enqueued as soon as is known to be weakly-referenced.
PhantomReference is a better alternative for finalize() method. As finalize() has performance problem and is unpredictable, we can use PhantomReference to do some pre-mortem cleanup.
For both SoftReference and WeakReference, the referent will be nullified before enqueued. And the garbage collector will finalize these referent at some future time.
As for PhantomReference, garbage collector will finish the finalization of referent and then enqueue the reference, but it will not nullify the referent. Thus PhantomReference must be used together with a valid reference queue, otherwise it's useless. And we have to clear the reference queue manually, if not, memory of the referent cannot be reclaimed by garbage collector.

Activity Leak Detection

How to Define Activity Leak?

In brief, if an activity has run over its onDestroy() method but garbage collector cannot reclaim its memory, the activity is leaked.

Activity Diagram

I made a activity diagram to demonstrate how to detect an activity leak in Android.

Register life cycle callback by void registerActivityLifecycleCallbacks (Application.ActivityLifecycleCallbacks callback).
On every activity's onDestroy() callback, create a WeakReference of it with a non-null ReferenceQueue.
Force the VM do a garbage collection.
Check the reference queue, if the reference we created before has not been enqueued, it's very likely that it leaks.

Further Explaination

void registerActivityLifecycleCallbacks (Application.ActivityLifecycleCallbacks callback) only supports Android API level 14 and above. If you need compatibility for API level below 14, you can substitute mInstrumentation in ActivityThread with your own implementation. It's not hard to do with reflection. But on some few third-party ROM which modified the ActivityThread.java, this method does not work. As ActivityThread is not in public API, this method doesn't guarantee to work on future Android versions.
Actually, there's no way to force the VM do garbage collection. We can only suggest the VM to do a garbage collection, but we can't guarantee it really did. That's why I said it is just very likely that the activity leaks if its reference is not enqueued after a forced garbage collection. There will be a few false positives due to Java garbage collector's behavior.
Here's code taken from Android Finalization Tester:
```
public static void induceFinalization() {
    System.gc();
    enqueueReferences();
    System.runFinalization();
}
```

We can't check reference queue immediately, as garbage collector need time to enqueue references, but we don't have a programmatic way to determine the time, we can only use an empirical value. Here's the implementation of enqueueReferences():

public static void enqueueReferences() {
    /*
     * Hack. We don't have a programmatic way to wait for the       reference queue
     * daemon to move references to the appropriate queues.
     */
    try {
        Thread.sleep(100);
    } catch (InterruptedException e) {
        throw new AssertionError();
    }
}

Efficient Thread-safe Singleton in Java

Shunix — Wed, 21 Dec 2016 12:16:40 GMT

Single-threaded Version

class Foo {
    private static Helper helper;
    public static Helper getHelper() {
        if (helper == null) {
            helper = new Helper();
        }
        return helper;
    }
}

The code works fine in single thread case. If multiple threads access getHelper() method simultaneously, they may try to create multiple objects or some of them may get an incompletely initialized object.

Naive Thread-safe Version

class Foo {
    private static Helper helper;
    public synchronized static Helper getHelper() {
        if (helper == null) {
            helper = new Helper();
        }
        return helper;
    }
}

The code is thread-safe, but synchronize the whole getHelper() method is unnecessary. Actually, only when multiple threads try to initialize helper, synchronization is needed. After helper initialized, simultaneous access to getHelper() works correctly without synchronization. It should return the same object.

Double-checked Locking Version

class Foo {
    private static volatile Helper helper;
    public static Helper getHelper() {
        Helper result = helper;
        if (result == null) {
            synchronized(Foo.class) {
                result = helper;
                if (result == null) {
                    result = new Helper();
                    helper = result;
                }
            }
        }
        return result;
    }
}

We optimized getHelper() method in the following manner:

Check if helper is initialized, if so, return it immediately.
Obtain lock.
Double-check if helper is initialized, other thread may have already initialized it.
Initialize helper.

The volatile keyword is necessary here. Prior to JDK 1.5, the compiler may reorder instructions. As a result, there's no way to guarantee an object's fields are all initialized before it's visible to other thread. Other thread may hold a reference to an incompletely initialized object, which may cause crashes.
Since JDK 1.5, volatile provide Happened-before guarantee, it make sure of these two things:

If Thread A writes to a volatile variable and Thread B subsequently reads the same volatile variable, then all variables visible to Thread A before writing the volatile variable, will also be visible to Thread B after it has read the volatile variable.
The reading and writing instructions of volatile variables cannot be reordered by the JVM.

There's no chance a thread see an incompletely initialized object. Double-checked locking idiom only works on JDK 1.5 or later. And it requires good understanding of java memory model.
Local variable result here slightly optimized the performance. Accessing volatile variable requires the variable to be read or written to main memory rather than CPU cache. If helper is already initialized, we only access volatile variable once due to "return result" instead of "return helper".

Initialization-on-demand Version

class Foo {
    private Foo() {
    
    }
    private static class FooHolder {
        private static final Foo INSTANCE = new Foo();
    }
    public static Foo getInstance() {
        return FooHolder.INSTANCE;
    }
}

Java Language Specification specified that the static class FooHolder is not initialized until the JVM determines it must be executed. Until getInstance() gets called, INSTANCE will not be initialized. Since the class initialization phase is guaranteed by the JLS to be serial, no further synchronization is required.

Enum Version

enum Foo {
    INSTANCE;
}

Implementing singleton with enum is recommended by Effective Java. Creation of enum is thread-safe, it's guaranteed by JVM. Compared with other implementation, enum version has unique advantages:

It prevents creating another instance via reflection, although you can work around this in previous version by throwing exception in private constructor.
If you're dealing with a serializable singleton, as deserialization will always create a new instance, you have to discard it by implementing readResolve() method and handling singleton state carefully. But with enum singleton, serialization and deserialization is guaranteed by JVM.

Avoid Memory Leaks in Android

Shunix — Thu, 08 Dec 2016 12:33:23 GMT

Java is a garbage-collecting-language, the garbage collector deals with memory properly on most cases. But we may still encounter memory leaks due to some logical bugs. I'll list some common cases that cause memory leaks in Android.

Static Reference

I just take static reference to activity for example. It's a typical case.
If an activity's onDestroy() method gets called, garbage collector should be able to recycle it. But garbage collector cannot recycle an object if other GC root holds strong reference to it. I used to see code like this:

public class MyApplication extends Application {
    public static Activity sTopActivity;
}

The programmer intends to hold a static reference to the activity on top of the stack. If this reference doesn't get reassigned on every activity's onCreate() method, it may cause activity leaks. Extending activity's lifecycle is dangerous, if you find you have to it, reconsider your design.

Handler

IdleHandler

/**
 * Callback interface for discovering when a thread is going to block
 * waiting for more messages.
 */
public static interface IdleHandler {
	/**
	 * Called when the message queue has run out of messages and will now
	 * wait for more.  Return true to keep your idle handler active, false
	 * to have it removed.  This may be called if there are still messages
	 * pending in the queue, but they are all scheduled to be dispatched
	 * after the current time.
	 */
	boolean queueIdle();
}

We may call this method to add IdleHandler to a message queue:

/**
 * Add a new {@link IdleHandler} to this message queue.  This may be
 * removed automatically for you by returning false from
 * {@link IdleHandler#queueIdle IdleHandler.queueIdle()} when it is
 * invoked, or explicitly removing it with {@link #removeIdleHandler}.
 * 
 * This method is safe to call from any thread.
 * 
 * @param handler The IdleHandler to be added.
 */
public void addIdleHandler(IdleHandler handler) {
	if (handler == null) {
		throw new NullPointerException("Can't add a null IdleHandler");
	}
	synchronized (this) {
		mIdleHandlers.add(handler);
	}
}

If we didn't remove idle handler manually, Looper.loop() will keep running, mIdleHandlers holds reference to idle handler we added before, the idle handler may hold reference to the activity if it's a non-static inner class, thus cause activity leaks.
So make sure to remove idle handler on activity's onDestroy() callback.

Delayed Message

If we post a message or runnable with sendMessageDelayed(Message msg, long delayMillis) or postDelayed(Runnable r, long delayMillis), there's a chance that these messages haven't been handled yet when the activity finished. Messages in message queue hold reference to handlers, handlers may referencing activity if it's a non-static inner class.
Remove all messages in onDestroy() or make the handler class static can both avoid activity leaks.

Thread and AsyncTask

Life cycle of a thread is unpredictable, it's very likely that threads created in activity haven't finished execution after activity's onDestroy() get called. Thread and AsyncTask holds reference to activity if it's a non-static inner class. Activity cannot be recycled before worker thread finish execution.
To solve this problem, we made these inner class static. If static inner class needs access to activity's member field, create a WeakReference inside the static inner class, it won't prevent garbage collector from recycling the activity.

WebView

Before Android Honeycomb, there's a disgusting bug with WebView, if the context passed to webview is activity's context, this activity can't be recycled, if it's application's context, this webview can't show dialog and start other activity.
To work around this problem, we usually start webview in a separate process. Once the webview finish its work, we kill the process to avoid memory leak. If the webview process need to exchange data with main process, we need to implement some AIDL interface.

Monitor Android Looper

Shunix — Fri, 02 Dec 2016 10:01:25 GMT

As I write in the previous post Android Message Handling Mechanism, all messages dispatched to main thread will be handled in the looper of main thread. If a message cost a long time, Android will report an ANR. It's necessary for a monitor library to detect ANR, so I need to log time costs for handling each message and report when the time reaches a threshold.
Let's begin with the code of Looper.loop():

public static void loop() {  
    final Looper me = myLooper();
    if (me == null) {
        throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
    }
    final MessageQueue queue = me.mQueue;

    // Make sure the identity of this thread is that of the local process,
    // and keep track of what that identity token actually is.
    Binder.clearCallingIdentity();
    final long ident = Binder.clearCallingIdentity();

    for (;;) {
        Message msg = queue.next(); // might block
        if (msg == null) {
            // No message indicates that the message queue is quitting.
            return;
        }

        // This must be in a local variable, in case a UI event sets the logger
        Printer logging = me.mLogging;
        if (logging != null) {
            logging.println(">>>>> Dispatching to " + msg.target + " " +
                    msg.callback + ": " + msg.what);
        }

        msg.target.dispatchMessage(msg);

        if (logging != null) {
            logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
        }

        // Make sure that during the course of dispatching the
        // identity of the thread wasn't corrupted.
        final long newIdent = Binder.clearCallingIdentity();
        if (ident != newIdent) {
            Log.wtf(TAG, "Thread identity changed from 0x"
                    + Long.toHexString(ident) + " to 0x"
                    + Long.toHexString(newIdent) + " while dispatching to "
                    + msg.target.getClass().getName() + " "
                    + msg.callback + " what=" + msg.what);
        }

        msg.recycle();
    }
}

Obviously, we only need to care about the execution time of msg.target.dispatchMessage(msg). I was thinking about hook Handler.dispatchMessage(Message msg) via Xposed, but Xposed works on class-level, I'll get the execution time of all handler instance. Actually, I just wanna monitor the message handling time of main looper. So can we do it with a lighter way?
Look at these lines:

Printer logging = me.mLogging;
if (logging != null) {
    logging.println(">>>>> Dispatching to " + msg.target + " " +
            msg.callback + ": " + msg.what);
}

msg.target.dispatchMessage(msg);

if (logging != null) {
    logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
}

Looper will print logs before and after handling message. We can consider the time difference as message handling time cost. All we need to do, is replace the mLogging with a customized printer. I write a monitor class to do this work:

package com.shunix.droidsentry.monitor;

import android.os.Looper;
import android.util.Printer;

/**
 * @author rayewang
 * @since 2016/11/23
 */
public class LooperMonitor {
    private final static int INTERVAL_THRESHOLD = 50;

    private static ThreadLocal sInstance = new ThreadLocal();

    public static void monitor() {
        if (sInstance.get() != null) {
            throw new RuntimeException("One looper can only be monitored once!");
        }
        Looper myLooper = Looper.myLooper();
        if (myLooper == null) {
            throw new IllegalStateException("The current thread must have a looper!");
        }
        sInstance.set(new LooperMonitor());
        myLooper.setMessageLogging(new LooperPrinter(myLooper));
    }

    static class LooperPrinter implements Printer {
        private final static String START_TAG = ">>>>> Dispatching to ";
        private final static String END_TAG = "<<<<< Finished to ";

        private Looper mLooper;
        private long mStartTime;
        private long mEndTime;

        public LooperPrinter(Looper looper) {
            mLooper = looper;
        }

        @Override
        public void println(String s) {
            if (s.startsWith(START_TAG)) {
                mStartTime = System.currentTimeMillis();
            } else if (s.startsWith(END_TAG)) {
                mEndTime = System.currentTimeMillis();
                if (mStartTime != 0) {
                    long interval = mEndTime - mStartTime;
                    if (interval > INTERVAL_THRESHOLD) {
                        // TODO report to server
                    }
                }
            }
        }
    }
}

To use this class, just call LooperMonitor.monitor(), this class will monitor the looper of calling thread automatically.