前些日子在研究学校的一卡通安全，在此记录一下一卡通破解的全过程，仅用作学习交流，切勿用于违法用途

 其他几篇： 一卡通(M1卡)破解过程记录——准备篇              理论篇             获取扇区密钥

到这一步时，一卡通的破解可以说已经成功了。一般来说，为了便于读卡器使用固定算法验证金额，一所学校下所有的一卡通在某一金额时的数据应是相同的，这也就导致了对一卡通数据的重放攻击可以被简单的实现。重放攻击是指将一卡通使用之前的数据保存下来，当一卡通余额用完时，将之前的数据重新写入到卡中，将同一个数据重复使用，达到无限次消费的目的。但我们不要仅仅止步于此，研究出数据的作用和校验算法以实现自由更改金额会更有成就感。

我校学生宿舍的水卡机是不联网的，所以可以确定重放一卡通水卡区的数据时不会因为与服务器端数据对账不通过而无法使用。经过反复测试，可以确定水卡系统安全性非常低，攻击者可以通过重放数据随意使用。

我校一卡通的饭卡消费机是联网的，但在实际的测试中，对数据重放后仍可还原金额值并通过卡机验证。重放数据生效说明饭卡机在认证身份时并未上传饭卡金额数据到服务端验证，消费完原有金额重新导入数据仍可正常使用。而在饭卡充值时就安全的多了，其在充值后会与服务器端比对卡中的数据，如果信息异常，则会将卡拉黑，此时需要补办卡才能正常使用。对于饭卡联网却不比对金额的原因，我推测是因为在用餐高峰期间实时校验信息的会导致网络的拥塞，几千人的不间断消费会频繁的读写数据，加重数据库的负担，如果产生延迟的话就会影响到饭卡的正常交易。

使用WinHex软件打开导出的dump数据，观察到其有256行数据，即该卡有256块，符合M1 4k卡的设计标准。第64行之后的数据只包含各扇区的默认密钥及控制位，说明该卡实际使用容量不到1kb,而在前16个扇区中0-9扇区同样使用了默认密钥及控制位，如图5-1所示，0扇区0块的数据依次为4字节的UID、1字节的BCC校验位、1字节的SAK、2字节的ATQA和16字节的制造商信息，关于0块的各值作用已在前文介绍，此处不再赘述。

   0扇区数据