Cocoa Oikawa

iOS保护应用安全,拒绝forwardInvocation (╯°□°)╯︵ ┻━┻

在 iOS 逆向工程的论坛上看到了如何勾住一个类所有方法的帖子,然后基本都是用 Objective-C 里的 forwardInvocation: 来做的,例如

Hooked via forwardInvocation
Hooked via forwardInvocation

于是这里做了一个检测自己的类是否被这样给 hook 了的方法。

继续阅读iOS保护应用安全,拒绝forwardInvocation (╯°□°)╯︵ ┻━┻

玩玩咕咕机——将 WordPress 站点的评论打印到咕咕机上w

之前在空间里看见过同学发咕咕机的分享,那时还是第一代咕咕机,然后这几周在 @DIYgod 那边也看到了咕咕机,于是就入了一个来玩玩w

看着非常有趣的咕咕机,然后想自己在这上面折腾点啥东西,于是就有了这个 WordPress 插件,它可以将站点的评论打印到咕咕机上www

第一条打印出来的评论w
第一条打印出来的评论w

继续阅读玩玩咕咕机——将 WordPress 站点的评论打印到咕咕机上w

和元宝酱做了一个公众号——多面的电影之思\(≧▽≦)/

管理员元宝(全名是人见人爱陈元宝)是学社科的大学森,我则化身为cocola~某一天元宝和cocola聊天的时候讲到:一千个人眼中有一千个哈姆雷特,很多时候,事情本身没有改变,只是看待事情的角度变了。于是这个公众号就诞生了,因为想知道,一部电影,从不同的视角出发到底可以看到多少,可以发散到多广。不同学科或者领域的朋友,看到的东西可能会大有不同。元宝和cocola决定选择一部电影(大多是经典),从不同角度进行反复讨论(⁎⁍̴̛ᴗ⁍̴̛⁎)

初心就是:探索和交流

最后欢迎学心理学、人类学、经济学、物理学等等且喜欢电影的小伙伴加入(/ω\)

欢迎大家来围观\(≧▽≦)/

我们的二维码w
我们的二维码w

2 Days at LinuxCon 2017

有幸获得了 HACKx 赠送的 LinuxCon 2017 门票,于是便动身参加了 LinuxCon 2017,这也是 LinuxCon 首次在国内举行,顺便也在大会上见到了 Linus Torvalds。

Linus Torvalds @LinuxCon 2017
Linus Torvalds @LinuxCon 2017

这次的 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。

SUSE CaaS Platform 3 Key Technology Components v1.1
SUSE CaaS Platform 3 Key Technology Components v1.1
Source: https://www.suse.com/communities/blog/suse-caas-platform-whats-buzz/

关于 SUSE CaaS Platform 的更多信息,可以参考 SUSE 官方的博客

接下来则是 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 可以在一起商量策略,设计一个使你们最大可能获胜的方案。那么传统的策略有两种,一种是确定型的,另一种是随机的。下面进入你们的讨论过程吧。

继续阅读量子力学在奇偶游戏中的运用

One simple means to defend Wi-Fi availability

前面写了 3 篇有关如何攻击 Wi-Fi 可用性的 post,于是这里也来简单的介绍一下自己所想的一个非常简单的、用于保护 Wi-Fi 可用性的思路。现实生活中的情况总是复杂的,不过个人认为下面这个思路在理论上来看是成立的(也或许实践中早有公司应用),没有过多的问题,当然这也有它自身的局限性,似乎还没有一个足够完美的方案(如果有的话,业界应该早就推广开了)。

我们已经提到过三种攻击,分别是 Deauthentication FloodBeacon FloodAuthentication Flood,这三种攻击都需要攻击者发送数量非常多的包才行。于是我们也可以反过来利用这一点。

FSPL From 2412 MHz to 2472 MHz
FSPL From 2412 MHz to 2472 MHz

继续阅读One simple means to defend Wi-Fi availability

IEEE 802.11 Denial-of-Service: Authentication Flood

这是另一个 IEEE 802.11 攻击的方法,算上前面两篇

就收集齐了 IEEE 802.11 中最简单的三种可用性攻击。这三种方法不涉及任何密码学的东西,仅仅需要靠近受害者的网络范围,然后嗅探到几个包就可以开始攻击,并且足以让被攻击的人完全用不了无线网络。

这篇 post 中所描述的 Authentication Flood 与第一个 Deauthentication Flood 相对应。Deauthentication Flood 是强制让一个 AP 上、已经建立 association 的 STA 断开,从而达到目的。而Authentication Flood 则是通过伪造一大堆请求认证的包(其实还有 Association Flood,与这篇 post 中的方法相似),来塞满 AP 中的 Authentication / Association table,这样,真正的用户只能等到这个表有空 entry 的时候才能和 AP 建立连接了。

Authentication Flood
Authentication Flood

继续阅读IEEE 802.11 Denial-of-Service: Authentication Flood

すごーい!たーのしー!