0x00 提出问题
-
一般遇到这个问题，我们会看到类似于这样的错误信息

The locale requested by LC_CTYPE=UTF-8 isn't available here.
Running `locale-gen UTF-8' may be necessary.

mosh-server needs a UTF-8 native locale to run.

Unfortunately, the local environment (LC_CTYPE=UTF-8) specifies
the character set "US-ASCII",

The client-supplied environment (LC_CTYPE=UTF-8) specifies
the character set "US-ASCII".

locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=
LANGUAGE=
LC_CTYPE=UTF-8
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
Connection to 128.199.. closed.
/usr/local/bin/mosh: Did not find mosh server startup message.

locale 就是指当前系统所使用的语言文件设定

0x01 发现问题
-
从错误信息和各种 Github Issue 中剖析可知，mosh 要正常工作，需要满足两个条件：

  1. 本地用的 locale，远端需要有对应的 locale 文件

    （Client 所使用的 locale 设置，会被 mosh 发送到 Server 进行比对，让 Server 设置到同一个 locale 上。）
  2. 目前所使用的 locale 需要是 UTF-8 的编码

0x02 解决问题
-

  1. 首先确认本地使用的是 UTF-8 的 locale 设置。

    使用 `locale` 来确认当前使用的 locale 设置，如果所有的参数值都带有 `.UTF-8` 字样，则说明没有问题。
*（ `LC_ALL` 是指全局的 locale 设置，其他的参数是不同情景的设置，比如可以让显示时间、货币等特殊字段时，使用不同的 locale。）*

  2. 如果不是 UTF-8 或者需要改个语言

    使用 `locale -a` 可以获取到所有已经安装的 locale，找一个自己需要语言的 UTF-8 版本的 locale，然后在环境变量中直接设置 `LC_ALL` 为对应的 locale 名字。

    Bash：export LC_ALL="en_US.UTF-8"

Fish：set -xg LC_ALL "en_US.UTF-8"

  1. 确认服务器上有这个 locale

    同样的，使用`locale -a`查看当前已安装的 locale 设置。

如果没有，Ubuntu 可以使用 `locale-gen en_US.UTF-8` 生成一个。
而 Debian 下这个命令虽然存在，但并不是用于生成新的 locale 文件，需要使用 `dpkg-reconfigure locales` 来对 locale 进行重新配置，来生成新的 locale 和设置默认的 locale。

0x04 吐槽
-
mosh 的好几个问题可以说是老生常谈了，比如 scroll 的支持，locale 的问题，都有许多的相关 issue。
感觉 mosh 的错误提示太模糊了，或者应该提供一个 ignore-locale 的选项。
然而，mosh 的 contributor 却丢一句

This looks like it is probably not a Mosh-specific problem.

emmm 总不能把这问题永远留在 issue 里面啊。

0x03 相关
-
https://unix.stackexchange.com/questions/246846/cant-generate-en-us-utf-8-locale

Debian, interactive: dpkg-reconfigure locales
Debian, automated: sed -i 's/^# *\(en_US.UTF-8\)/\1/' /etc/locale.gen && locale-gen
Ubuntu, automated: locale-gen en_US.UTF-8

https://github.com/mobile-shell/mosh/issues/793
https://github.com/mobile-shell/mosh/issues/678
http://www.jianshu.com/p/386c80192f8e

0x00 到底哪个好？
-
因为打游戏和别人语音需要用到 YY 和 QQ，而我又实在不想把这两个流氓装在电脑上，于是丢进了虚拟机里。

因为是日常使用，并不是开发用途
所以3D加速让界面能够跟手一些，用的更舒服一些，以及音频设备的延迟能低一些让语音的体验更好，是我的主要需求。

0x01 开始折腾
-

Vmware:
先试着用了一直在电脑里装着的 VMware Workstation 12.x。
然而这个版本在 Windows 10 下的的 3D 加速效率和音频设备延迟有点受不了....
Mic 和 Speaker 延迟都有大概 0.5 秒左右。
于是更新到 14.x，3D 加速似乎工作的不错，流畅了许多，然而音频设备的延迟并没有任何改善，甚至发现引入了新的bug：

在 VMware Workstation 14.x 目前的最新版中(截止 2017-10-10)，当3D加速开启，CPU逻辑核心数大于1，且频繁调用音频设备时（比如打开YY），就会使宿主机的 VMware 进程直接崩溃 (日志显示 access violation)

*在这里插个题外话，说起 VMware，就不得不想起我在 mac 上使用的虚拟化方案 —— VMware Fusion。
花了 1700 买了两个 VMware Fusion 的大版本更新，使用感受上一些都还是那么的屎....*

Hyper-V:
于是卸载 VMware，打开了 Windows 10 自带的 Hyper-V，毕竟巨硬官方加持，可能直接从操作系统底层的资源分配上就更具优势，甚至可能支持 PCI Passthrough。

然而试了一下发现，将其 3D 加速功能的所依托的 RemoteFX 设备添加至 Guest 后，只有通过RDP访问虚拟机界面才有效果，而但从界面的流畅程度来说，甚至还不如打开3D加速。（可能 RemoteFX 的思想就只是为了让需要3D加速的应用能跑起来而已）
而至于 Hyper-V 模拟音频设备，完全没有实现这种东西，只能通过RDP来获取远程音频....
至于 PCI Passthrough，似乎只有 Server 版才有这个功能。

VirtualBox:
醉了，于是把目光转向几年前并没有给我什么好印象的 VirtualBox。
如今的 VBox 已经更新到了 5.1.28，令人惊讶的是在各方面的表现都要比前两者要好...
而我在 UserManual 里还看到了 PCI Passthrough 支持的相关文档，看起来应该是支持，不过还没有尝试。
而 3D 加速和音频设备的延迟表现也都很优秀（可能全靠同行衬托）

For Mac:
于是准备把 Mac 上的 VMware Fusion 也换成 VBox 试试，但是在VMware Fusion 10 和 VirtualBox 的较量中，似乎 VMware For Mac 还是更胜一筹，于是在 Mac 上仍然留用VMware。

0x00 十年过去了
-
距离 M1 卡的加密验证缺陷被公开已经过去了十年左右，然而大量基于M1卡储存的系统仍然没有对安全问题进行有效的处理...

而离广大少年黑客最近的，便是学校的各种充值卡系统了，在一些学校里，饭卡水卡的余额储存仍然是完全依赖于 M1 卡本身的储存来实现的，当然我们学校的水卡也不例外，否则也不会有这篇文章了。

破解离线水卡系统的文章千千万，基本思路都是用现成的工具，通过 Nested Authentication Attack 获取 Key，然后就可以对卡的扇区进行读写操作了，但是与开发者所额外添加的一些安全措施进行对抗的这一过程，仍然是有趣且值得实践一番的。

0x01 简单的记录
-

  1. ACR122U 一台，用于读取 M1 卡
  2. mfoc，kali linux 自带工具，用于进行 Nested Authentication 攻击，获取扇区的 KeyA 和 KeyB
  3. Mifare Classic Tool(MCT)，Android APP，可以利用手机的 NFC 对卡进行读写，需要手机支持 NFC NXP 协议
  4. M1 有 16 个扇区，除了 0 扇区存着卡的 UID 和各种厂商信息之外，其他的扇区持有 KeyA KeyB 就可以任意的读写

0x02 简单的重放攻击
-
通过 mfoc 破解出 Key，将关键数据的扇区数据使用 MCT Dump 下来，等水卡没钱了直接写进去就好了，似乎没有什么好写的。

0x03 与额外的安全措施对抗
-
因为 M1 卡的弱点，导致数据很容易被读出来，而受制于成本，系统开发者又不能随意的引入服务器来对数据进行验证。于是各种千奇百怪的数据加密和混淆方法出现在了各种系统上。

最开始把注意力放在数据和 UID 的关系上，但是发现这种思路没有太大意义，因为UID没有规律。
于是转移到“每刷一次卡就 dump 一次数据，基于金额的变化来推测”的这种思路，又多找了几张卡来交叉对比，防止引入了 UID 作为变量来共同计算数据。

而在半年的时间内不间断的尝试，我也幸运的找到了我们学校水卡数据的储存方式....
只需要把第 14 扇区的前16个字节与固定的 table 进行 xor 就可以了，使用了其中2个字节以分为单位来储存金额，也就是说最大金额为 655.35 元
并且金额数据后的两个字节作为校验位，也是将 UID 的最后的一个字节和固定的数据进行 xor，令人不解的是，校验位引入 UID 和金额两个变量明显会更有效，然而开发者并没有这么做。

然而距离成功一步之遥的时候，校验位的第二位却不按套路出牌，找不到规律了。不过反正只有一个字节，256个可能性直接爆破一下就好了。于是最后参考了一下NFC-Utils的读写代码，写了一个全自动爆破 Key，通过滑条方便的修改余额的 APP。用户体验自我感觉相当良好（呸）

至此，强度并不高的混淆算法宣告破解。

watercard.png

对于弱类型语言总有一种说不出的厌恶感
无数个让人摸不着头脑的 Magic behavior，需要背的 True Table 等等
让人感觉像是生错了世界...

说了这么多其实是开个坑，想要把 Python 的各种 import 姿势弄清楚到底有什么区别

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5