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 姿势弄清楚到底有什么区别