iOS保护应用安全，拒绝forwardInvocation (╯°□°）╯︵ ┻━┻
在 iOS 逆向工程的论坛上看到了如何勾住一个类所有方法的帖子，然后基本都是用 Objective-C 里的 forwardInvocation: 来做的，例如
于是这里做了一个检测自己的类是否被这样给 hook 了的方法。
玩玩咕咕机——将 WordPress 站点的评论打印到咕咕机上w
之前在空间里看见过同学发咕咕机的分享，那时还是第一代咕咕机，然后这几周在 @DIYgod 那边也看到了咕咕机，于是就入了一个来玩玩w
看着非常有趣的咕咕机，然后想自己在这上面折腾点啥东西，于是就有了这个 WordPress 插件，它可以将站点的评论打印到咕咕机上www
西西里的美丽传说——爱欲与占有欲
那时你坐着专心做女红
对美好的前途满怀信心
当时是芬芳的五月 你总爱这样度过辰光
——A Silvia
本文涉及电影内容，请注意会被剧透哦w
和元宝酱做了一个公众号——多面的电影之思\(≧▽≦)/
管理员元宝（全名是人见人爱陈元宝）是学社科的大学森，我则化身为cocola～某一天元宝和cocola聊天的时候讲到：一千个人眼中有一千个哈姆雷特，很多时候，事情本身没有改变，只是看待事情的角度变了。于是这个公众号就诞生了，因为想知道，一部电影，从不同的视角出发到底可以看到多少，可以发散到多广。不同学科或者领域的朋友，看到的东西可能会大有不同。元宝和cocola决定选择一部电影（大多是经典），从不同角度进行反复讨论(⁎⁍̴̛ᴗ⁍̴̛⁎)
初心就是：探索和交流
最后欢迎学心理学、人类学、经济学、物理学等等且喜欢电影的小伙伴加入(/ω＼)
欢迎大家来围观\(≧▽≦)/
2 Days at LinuxCon 2017
有幸获得了 HACKx 赠送的 LinuxCon 2017 门票，于是便动身参加了 LinuxCon 2017，这也是 LinuxCon 首次在国内举行，顺便也在大会上见到了 Linus Torvalds。
这次的 LinuxCon 实际上是三个会议，其一不用说，就是 LinuxCon 了，然后是 ContainerCon 和 CloudOpen，官方合称为 LC3。此次 LC3 的 Keynote 和各展商的 Presentation 覆盖了以下 10 个方面
- Programming Frameworks 编程框架
- Application Platforms 应用平台
- VM / VIM Managers 虚机管理
- Containers 容器
- Operating System 操作系统
- Virtual Machines 虚拟机
- Network Management & Orchestration
- Carrier Networking 运营商网络
- Network Controller 网络控制
- Data Plane Services 数据平面服务
在这 10 个方面上，作为支撑的则是
- Security 安全性
- Governance, Operations & Ecosystem 运维
- Licensing & IPR 许可和知识产权
- Training & Certification 培训和认证
除了 Keynote Session 之外，各展商的 Presentation 都是同时在不同会议室展开的，我只去听了其中几场
- Much Ado About Blocking: Wait/Wake in the Linux Kernel - Davidlohr Bueso, SUSE Labs
- Rethinking the OS: A Travel Journal - Simora Arsene, SUSE
- MD RAID1 and NVMe: High Performance Data Duplication - Coly (Yong) Li, SUSE Linux
- Kubernetes Bootcamp 101 - Caicloud
- LinuxCon K8S + TensorFlow Bootcamp 101 - Caicloud
要说什么的话，这次的 LC3 给我的感觉是（大部分）围绕 Container 来进行的，包括但不限于 SUSE、Intel、VMWare、Caicloud 在内的公司都在致力于为 Containter 提供更好、更易用、更安全的体验。
这里我挑选几个印象最深的来说说吧。
首先是 SUSE 正式发布了 SUSE MicroOS（Micro stands for Microservice），官方是这样描述的，
A purpose built Operating System designed for microservice & containers and optimized for large deployments.
一个专为微服务与容器打造的，且为大规模部署优化过的操作系统。
主要特点则是
- An always up-to-date Operating System
- An easy to manage/upgrade OS
- Easily setup/manage a cluster of nodes
- scalable - up to 1000s of nodes
An always up-to-date Operating System（一个总是最新的操作系统）。关于更新这一点，可能有人遇到过更新之后出现问题的情况，SUSE 在这边使用了 Atomic Upgrade（原子更新），保证了在更新期间，即使出现了问题，也能回滚到更新前的状态。接下来，SUSE 做到 always up-to-date 的方案则是，一直在后台拉取更新，然后在系统负载低时进行更新。
SUSE MicroOS 则是作为 SUSE CaaS Platform 的组成之一，剩下则是 Kubernetes 和 Container Engines。
Source: https://www.suse.com/communities/blog/suse-caas-platform-whats-buzz/
关于 SUSE CaaS Platform 的更多信息，可以参考 SUSE 官方的博客
- Introducing SUSE Containers as a Service Platform
- What is SUSE CaaS Platform? What’s all the buzz about?
接下来则是 Intel 的 Clear Linux 和 Clear Container 技术。需要注意的是，虽然这两个项目命名方式类似，但是实际上是两个不相干的项目。
Clear Container 技术是为了给现有的 Container 提供一个虚拟机级别（例如 VMWare）的隔离。在现有的 Container Engine 技术中，由于不同的 Container 共享的是一个 Linux Kernel，如果其中一个感染了可以取得 Kernel 代码执行权限的病毒，那么这个病毒就可以绕过 Container Engine 的隔离，感染所有正在运行的 Container。
在 Clear Container 中，Intel 目前实现了与 Docker 无缝对接，利用 Intel VT-x 实现了 Kernel 级别的隔离，因此不同的 Container 也可以运行在不同版本的 Kernel 之上。当然，虽说是无缝对接，但是实际上还是多了一层，即 Intel VT-x 那层，据 Intel 的说明，目前在内部测试出来的开销并不大，启动一个 Container 只多 20ms 的样子，但是对文件读取的开销还没有非常明确，目前是将文件映射到内存以尽可能降低这方面的开销。
Clear Linux 则是另一个项目，这个项目的目标是构造一个尽可能小的 Linux 用于 Container，并且内核模块全部使用静态链接的方式换取速度与安全，如果你有特别的需求的话，可以自己在 Clear Linux 的基础上编译内核（当然也都是静态方式）。目前 Clear Linux 的 Container 镜像仅仅 5 MB。
量子力学在奇偶游戏中的运用
假设你和你的朋友在外闲逛时，突然被邀请参加一个便于本文接着写下去的游戏——奇偶游戏。游戏的主持人告诉你们，两位参赛者，友人 A 和你（那么不妨称你为便于后文表示的友人 B 吧w），在正式开始比赛之后，处于相互隔离（即无法交换信息）的状态。游戏的主持者会随机选取两个二进制位 $x, y\in \{0,1\}$。然后 $x$ 会交给友人 A，$y$ 自然是交给你，即友人 A 知道 $x$ 是 0 还是 1，但不知道 $y$ 的值；类似的，你知道 $y$ 的值，但不知道友人 A 手上的 $x$ 的值。你们需要根据自己所知道的值，分别给出一个二进制位 $a, b\in \{0,1\}$ 作为回答。
在你们都给出了回答之后，主持者先计算 $a \oplus b$ 的值（$\oplus$ 代表异或运算），然后计算 $x\wedge y$ 的值。如果有 $a \oplus b = x\wedge y$，那么你们就获胜。（会获得什么奖品呢～我想要小裙子！）
假设在比赛开始前（或者说参赛前），你和友人 A 可以在一起商量策略，设计一个使你们最大可能获胜的方案。那么传统的策略有两种，一种是确定型的，另一种是随机的。下面进入你们的讨论过程吧。
IEEE 802.11 Denial-of-Service: RSN IE Poisoning
前面提到的方法都需要发送大量的数据包，而这篇 post 中的方法仅需要嗅探再加上少量的包就可以实现对使用 WPA / WPA 2 的用户进行攻击，使受害者无法连接上 AP。这种方法即 RSN IE Poisoning。
Continue reading IEEE 802.11 Denial-of-Service: RSN IE Poisoning
One simple means to defend Wi-Fi availability
前面写了 3 篇有关如何攻击 Wi-Fi 可用性的 post，于是这里也来简单的介绍一下自己所想的一个非常简单的、用于保护 Wi-Fi 可用性的思路。现实生活中的情况总是复杂的，不过个人认为下面这个思路在理论上来看是成立的（也或许实践中早有公司应用），没有过多的问题，当然这也有它自身的局限性，似乎还没有一个足够完美的方案（如果有的话，业界应该早就推广开了）。
我们已经提到过三种攻击，分别是 Deauthentication Flood，Beacon Flood 和 Authentication Flood，这三种攻击都需要攻击者发送数量非常多的包才行。于是我们也可以反过来利用这一点。
Continue reading One simple means to defend Wi-Fi availability
IEEE 802.11 Denial-of-Service: Authentication Flood
这是另一个 IEEE 802.11 攻击的方法，算上前面两篇
- IEEE 802.11 Denial-of-Service: Deauthentication Attack
- IEEE 802.11 Attack: Beacon Flood
- IEEE 802.11 Denial-of-Service: Authentication Flood
就收集齐了 IEEE 802.11 中最简单的三种可用性攻击。这三种方法不涉及任何密码学的东西，仅仅需要靠近受害者的网络范围，然后嗅探到几个包就可以开始攻击，并且足以让被攻击的人完全用不了无线网络。
这篇 post 中所描述的 Authentication Flood 与第一个 Deauthentication Flood 相对应。Deauthentication Flood 是强制让一个 AP 上、已经建立 association 的 STA 断开，从而达到目的。而Authentication Flood 则是通过伪造一大堆请求认证的包（其实还有 Association Flood，与这篇 post 中的方法相似），来塞满 AP 中的 Authentication / Association table，这样，真正的用户只能等到这个表有空 entry 的时候才能和 AP 建立连接了。
Continue reading IEEE 802.11 Denial-of-Service: Authentication Flood
IEEE 802.11 Attack: Beacon Flood
这是另一种 802.11 攻击，或者说扰乱更合适。攻击者发出无数个 Beacon 帧，这些 Beacon 帧既可以是和你的 AP 拥有相同的 SSID，也可以是攻击者自定的 SSID，或者就是一些随机字符串，取决于攻击的目的和实际环境。
