Feistel作为现代密码学中构造分组密码的常用对称结构，我很肯定老师在课上重点分析过。对于这个结构，记忆中一直是模糊的位或、16轮、F函数和纠缠在一起的交叉箭头。想来自己的memory palace也是够奇怪了，居然把feistel和round绑在了一起。直到前段时间无聊搞搞ECU通信加密TEA算法玩，看到图解分析的“1 round”才猛然想起feistel，却又记不起基础理论和实现细节。可能当初手算AES shiftrow mixcolumn留下的心里阴影太大，轰塌了DES大楼，行移位列混淆轮密钥加真^TM琅琅上口。一般教材进入现代密码学首先会介绍分组密码，尤以feistel密码结构为例，进而讲解DES的设计原理。如DES中所做的代换为了使密文唯一而可逆；扩散（P盒）能够弥补古典密码难以抵抗统计分析的弱点；混淆（S盒）则通过打乱密文与密钥的关系来保护密钥。文章中不打算详细分析分组密码，仅对feistel结构及用到相似设计的算法理解做一点记录。

两个月前

前阵子在群里和大家抱怨呢，实在实在没有心情写文章。调部门之后再没有研究安卓源码，翻译对我而言竟变成了一件耗时又极度枯燥的事情。用每天下班之后的两个小时把The Wire补到第四季是这几个月来唯一的成就。在Madoka酱的感shan染dong下，把黑河两周po个游记，毕竟business travel也是travel嘛。

0x00 产线很重要

今年赶手环项目的两个月加班加到飘飘欲仙，好在项目产品代理商客户都很给力，我一度觉得这个项目要凉，8月初拿到UI逻辑，timeline到中期了协议都还没敲定，最后竟然在春哥打鸡血般的带领下顺(惊)利(险)定版，虽然多少还有些问题，也算得上是个小奇迹了。有阵子每天凌晨一两点提交完代码大家就一起勾结去老细吃砂锅粥，一晃眼都年底了，项目组跑路的跑路换部门的换部门。人生よ……

内部入门 Internals Primer

正如我们之前所说，安卓源码可以自由地为人们所下载、修改以及安装至选择的机器中。实际上，仅仅是获取、编译代码，再将其运行在安卓模拟器这个过程并不值得一提。能够为你自己的硬件及设备客制化AOSP，做到这件事的前提是需要对安卓的内部结构有一定掌握。所以在这一章，我们先从一个较高的视角去看待安卓内部，在后续章节中再找机会深入理解各个部分。
As we've just seen, Android's source are freely available for you to download, modify, and install for any device you choose. In fact, it is fairly trivial to just grab the code, build it, and run it in the Android emulator. To customize the AOSP to your device and its hardware, however, you'll need to first understand Android's internals to a certain extent. So we'll get high-level view of Android internals in this chapters, and get opportunity in later chapters to dig into parts of internals in greater detail, including trying said internals to the actual AOSP sources.

很显然，这是一篇梗文

从16年11月开始写S.M.A.R.T.项目的主框架，直到答辩结束都一直没太敢更新arch。一来是怕万一滚挂了什么奇奇怪怪的依赖，恢复一下还是要花些时间的；二来呢，沉迷叛乱之后很少切linux了，工作日下班回来基本不太开电脑，周末就在 push push push 中度过

所以时隔一年半，这次 sudo pacman -Syu 果然还是出了不少问题：fcitx输入法全挂、gnome-control-center点不开，倒是gnome扩展让人感到很稳定，反正每次更新都挂每次都要重装。

首先是终端字体堆叠，等宽设置成文泉驿 Micro Hei Mono Rregular 基本ok，不过貌似影响了终端窗口大小

大问题是fcitx挂了，以往输入法一直都在，所以碰到什么问题随手一搜，解决到能用就行从不做记录。而这次的现象是fcitx中没有候选输入法可以选，怎么样都调不出输入设置。Wiki是个好东西，所以引一下arch fcitx wiki中所说：

首先诊断问题所在

当你遇到任何 fcitx 有关的问题，比如 ctrl+space 在有的程序中不能工作，首先应该用 fcitx-diagnose 命令诊断问题的原因。 fcitx-diagnose 会列出所有 fcitx 正常运行所需的前提条件，从输出结果中通常可以找到问题的原因。 在网上（比如在 irc 或者论坛里）询问别人关于 fcitx 配置的问题时，也请首先提供你的 fcitx-diagnose 输出结果（比如贴到 pastebin 服务），这将加速别人帮你找到问题所在

仔细看了下fcitx-diagnose输出，发现之前对GTK和QT的设置居然一直都是错的( ╯-_-)╯┴—┴，果然是以前盲从网上解法不认真看官方wiki，在xim里多写了一对双引号。。。

系统设置打不开，后来用 ps -ef | grep xxx 强杀之后重启ok

记录下常用的几个gnome扩展 Dash to Dock， System Monitor， NetSpeed Master

简介 Introduction
将安卓操作系统移植到嵌入式设备上是一项复杂的任务，这包括了对系统内部复杂设计的理解，巧妙地将修改融入到安卓开源项目，以及对内核运行平台——Linux的掌握。在开始进入到嵌入式安卓细节之前，先让我们了解一些安卓系统背后的本质内容，例如安卓的硬件需求，安卓的法律体制和对嵌入式设备的影响等。首先，让我们一起看一看安卓的诞生与发展。
Putting Android on an embedded device is a complex task involving an intricate understanding of its internals and a clever mix of modifications to the Android Open Source Project (AOSP) and the kernel on which it runs, Linux. Before we get into the details of embedding Android, however, let's start by covering some essential background that embedded developers should factor in when dealing with Android, such as Android's hardware requirements and the legal framework surrounding Android and its implications within an embedded setting. First let's look at where Android comes from and how it's developed.

前言

安卓的发展是现象级的。在极短的时间内，它已成功地成为市场上顶尖的手机平台。明确的说，谷歌的安卓团队使用了开源协议，积极面向市场，设计前沿的接口，这些超凡的组合正在开花结果。不必多说，大量用户的涌现也归功于安卓没有被手机制造商、移动网络运营商、硅谷制造商及应用程序开发人员所忽视。各种标记着“为安卓设计”的产品，“兼容安卓”的应用和“基于安卓”的设备都如雨后春笋般出现。
Android's growth is phenomenal. In a very short time-span, it has successded in becoming one of the top mobile platforms in market. Clearly, the unique combination of open source licensing, aggressive go-to-market, and trendy interface is bearing fruit for Google's Android team. Needless to say, the massive user uptake generated by Android has not gone unnoticed for handset manufacturers, mobile network operators, silicon manufacturers, and app developers. Products, app and devices "for", "compatible with", or "based on" Android seem to be coming out ever so fast.

做一个安卓系统OTA校验的记录

0x00 singal.emit()

去年七八月份的时候看同事出过一个插卡自动升级脚本，核心功能非常简单了，把外置卡的update.zip拷贝到内置卡，写升级命令到command后reboot recovery
今年过完年回来客户报了OTA的问题，给到的截图显示升级包校验失败，因为recovery里基本是G家源码没有改动过，所以基本可以判断是升级包不完整。保险起见嘛还是过一遍源码

0x01 源码

手上是一套4.4，OTA相关的内容在 path_to_source/bootable/recovery 路径下。关于安卓recovery和main
system的逻辑就不多说，结尾贴两篇大佬分析的文章看看基本ojbk。这里主要还是拿升级包对着verifier.cpp分析一波

概要

OpenSSL_CA使用C++语言编写，开发框架为QT(mingw)，目前使用的版本为5.7.0，理论上支持跨平台。 程序使用OpenSSL提供的API 目前已完成具备基本操作的1.0版本，正在重写2.0版本，包括以下工作：
1. 修复已知bug，重写函数
2. 重新设计UI，分离服务器及客户端
3. 统一代码风格，合并重复的代码块
4. 添加部分新功能，调整逻辑

开源地址： gitosc | github