2017年9月

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

0x00 小镇的网络
-
海外 IP 高位端口的 Inbound 流量全都被封了
原来用的是 Zerotier,不过不受自己控制的 Server 总感觉使用起来怪怪的。
49 那里了解到了 Tinc VPN
于是借着这个机会玩一玩高端大气上档次的 SDN/Mesh Network

0x01 安装
-
Stable 版本还没有便利的 join 功能,于是用 1.1-pre14 版本
用的是 49 打包的 deb

wget file.hestia.moe/tinc.deb
apt-get install liblzo2-2
dpkg -i tinc.deb

0x02 初始节点
-

tinc -n Networkname init Nodename
tinc -n Networkname add Mode Switch
tinc -n Networkname add Interface tinc
echo "ifconfig \$INTERFACE 10.1.1.1/16" >> /etc/tinc/Networkname/tinc-up
tinc -n Networkname start
tinc -n Networkname invite newNodename  # add a new invitation

0x03 新的节点
-

tinc join xxxxxxxxxxxxxxxxxxx  # Join via invitation string
echo "ifconfig \$INTERFACE 10.1.1.2/16" >> /etc/tinc/Networkname/tinc-up
tinc -n Networkname start

0x04 一些指令
-

tinc -n Networkname top  # 查看所有节点和实时流量

0x05 其他系统
-
macOS:

brew install tinc --devel

Windows:

安装tinc
安装TAP
GUI 配置 TAP 的网络适配器(最好写个网关,否则强制为公共网络)
把适配器改名叫 tinc
tinc.conf 加一行 Interface = tinc

0x00 冰冷的天里散热风扇胡乱地吹
-
冰凉的 mac 把它的体温通过C面手托传递给我的手

0x01 媒体键同学@提不起劲
-
这两天 volume up down 两个媒体键按下去总要一段时间才会有反应,似乎呈现出block几秒的状态

看了一眼系统信息
macOS X Sierra 10.12.3, Uptime 36 days

根据 discussions.apple.com 的一篇帖子

把 Audio Daemon 进程杀死之后,该进程在短时间内自动重新启动,媒体键反应恢复正常。
杀死 Audio Daemon 进程的命令是:sudo killall coreaudiod

于是问题解决

0xff Mac 继续着它的 uptime,如同每一台电脑
-
我在混乱的人生中寻求稳定和慰藉,如同大多数人
突如其来的文艺

0x00 奇怪的编码
-
今天做一个小题目,遇到了一个奇怪的编码方式,查看 Hint 之后发现使用了 UTF-9....
Emmmm.....

0x01 UTF-9 是啥
-
UTF-9 是 IEEE 在 2005年4月1日 愚人节
在 RFC4042 中规定的两种 Unicode 编码之一
这两种编码分别是 UTF-9 和 UTF-18

0x02 安装别人写的 utf-9 编码 module
-

git clone https://github.com/enricobacis/utf9
cd utf9
python setup.py install

刚装好的 minimal debian,提示没有 setuptools...

sudo pip install setuptools

又提示没有 pip....

sudo apt-get install python-pip

setup.py 可以跑了,报错 gnu gcc exit 1,提示找不到 Python.h 文件
在 /usr/include/Python2.7 里面确实没有,于是把 dev 包装好

sudo apt-get build-dep python2.7-dev
sudo apt-get install python2.7-dev
(这里忘记到底装的是什么了...)

于是安装好了

0x03 测试一下
-

>>> import utf9
>>> utf9string=utf9.utf9encode(u'pcat')
>>> print repr(utf9string)
"8\x18\xcc'@"
>>> print utf9.utf9decode(s)
pcat

0xff Ref
-
http://www.cnblogs.com/pcat/p/6422211.html