首页 » 技术分享 » 一卡通(M1卡)破解过程记录——数据分析(水卡、饭卡及门禁)

一卡通(M1卡)破解过程记录——数据分析(水卡、饭卡及门禁)

 

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

 其他几篇: 一卡通(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扇区数据

  

11-15扇区使用自定义的密钥,其中的数据用以实现校园一卡通的各种功能。如图所示,在15扇区右方的显示区域出现了我的一卡通对应的学号和姓名,可知该扇区用于存放学生信息,姓名使用GBK编码存储,每两个字节对应一个汉字,学号使用ASCII码存储。

15扇区数据

   

现在对一卡通数据重放,在热水机上多次消费并导出不同余额时的一卡通数据到WinHex,使用其自带的比对功能比对后发现只有块56和块57部分的数值发生了变化。14扇区的数据部分如图所示,可以看出变化的两块数据完全一致,因此水卡的金额必定与这两行数据有关。

14扇区数据

导出消费0.02元和消费0.04元后的数据,其水卡金额部分的内容如图所示,可以看到前2个字节的值每次减少0002,除以一百即为0.02元,所以前2个字节应该为水卡的金额值,将“01C8”转换为10进制并除以100,得到的结果为4.56,与此时一卡通的实际金额4.56元吻合。倒数第3个字节的变化也很有规律,每刷一次卡递加1,显而易见为一卡通的刷卡次数。最后两个字节的变化没有规律,但可以看出两两相加后的结果都为1D8。一卡通金额的部分一般都会设置校验位,校验位是通过和金额进行某种特殊运算核验数据,从而使篡改后的数据不可用。经过试错后得知该卡中所有数据都参与运算,也就是说除了“01 C6”外其他的数据都为校验位,修改整行数据的某一值都会导致卡机识别错误。设置了两行一样的金额数据是为了保证可用性,两行中有一行能通过校验即可读卡成功,读卡时先测试第一行数据,如果成功第二行就不进行校验,消费后将两行数据改为读卡器运算出的新数值。

 消费0.02元后的水卡金额

  

消费0.04元后的水卡金额

  

 0元卡的数据

RFID系统中小块数据的校验运算一般采用按位取反、CRC冗余校验、BCC异或运算及LRC和校验计算方法。难点在于确定运算的数据块,尽管你能通过比较找到变化的行数,但是很难判断出一行中哪几个字节是直接参与运算的。参照一张0元卡的数据,我们看到其最后两位比较独特,相加的结果为D8,而前面的几个数据中这两位的结果为1D8,舍弃进位后4张卡的倒数两个字节相加都为D8。这说明在校验运算中这部分的其中一个字节应该是分离出来的。我们用前14个字节与后四个字节中的两个分别尝试校验运算,最后发现使用前15个字节两两异或后的结果都为AA,AA是校验运算的一个特殊值,此时我们可以推测前15个字节使用了BCC校验运算。

 修改后的水卡金额数据

水卡金额位只占前2个字节,也就是其数值最大为FFFF,转换为10进制除以100得出其最大金额为655.35。我们将存储刷卡次数的数值保持不变,与FFFF及AA每两字节异或运算得到校验位数值并填入对应的位置,然后用D8减去第15字节的值后填入第16字节,如图所示。导入卡片测试被卡机识别,此时金额显示为655.35,与修改后的值一致,至此我们已经得到了水卡金额的校验算法。

前面我们测试得知了一卡通中饭卡时联网的,水卡数据是不联网的,水卡的数据校验不匹配热水机就会读卡出错,但此时在饭卡机上是可以正常使用的这说明在不同的功能中验证的数据有可能是相互独立的。因此我们导入同一卡下不同的扇区数据到CUID白卡中测试,从而找到不同功能使用的相应扇区。

   

在水卡测试中读卡器只验证14扇区的水卡金额部分,修改其他扇区的数据不会影响水卡的使用。在饭卡测试中读卡器首先会验证0扇区部分,因为0扇区部分存放卡片UID,在正常情况下卡片UID是不可修改的,所以通过将UID与数据库中的UID,就可以在一定程度上保证卡片的真实性,防止他人克隆卡片使用,消费信息的同步也通过UID来实现,消费完成数据库端会查找该UID对应的信息修改。但这种方法对于可重复修改UID的CUID卡片是无效的,CUID卡可将自身的UID修改为其他卡的UID达到伪装的效果。

但仅仅使用UID来验证是不够的,因为UID信息不加密,只要用读卡器识别一下就可以读取到卡片的UID,如果仅用卡片的UID验证,那么我可以使用读卡设备在校园里扫描,一般一卡通放在口袋中,只要使用读卡器在4cm的范围内感应就可获取到他人的UID,而拿到UID后若将金额扇区重放,就可以冒用别人的身份信息消费,这样就算服务器对账出现问题追查时也难以找到实际责任人,一卡通系统显然不能让这么大的漏洞存在,因此又在44块的位置存放了一个卡号,如图所示,自动贩卖机显示本人一卡通卡编为66809,在44块找到对应数据为104F9,修改该数据后读卡就会出错。发卡编号与学生信息对应,就算补办新卡仍不会变化,学号每加1位这个卡号就会加1,并且与卡片的UID号对应,通过这联网验证该数据在一定程度上保障了卡的真实性。但使用这种方法仍有弊端,在自动贩卖机前排队时可先用设备感应到他人卡片UID,然后在他人刷卡时观察贩卖机上显示的卡号,即可将UID号和卡号对应起来,冒用他人信息重放饭卡金额来使用。

44块包含了发卡编号参与联网校验

13扇区存放饭卡数据,其中前3个字节"0022C4"代表金额,转换为10进制为8900,也就是我此时的余额89元。0155为消费次数,代表我已消费了341次,这个数据存放在卡中,每消费1次就会加1,补办新卡就会清零,但同时服务器数据库中也会记录你的消费次数,但不进行核验,我在智慧校园查到的消费次数是1088,而这张卡只有341次是由于这张卡是后来补办的新卡。

消费5.7元

块2前6个字节是上笔消费的时间,如图消费时间为5月17日16点03分21秒17毫秒,右边的0003E8出现了两次,代表消费的金额,转换10进制后为1000,对应我消费的金额10元。我学校的饭卡系统虽然联网,但可能考虑到高并发的情况没有和服务器实时对账,刷卡时先验证44块处的发卡编号是否与卡片UID在数据库中对应,如果对应,读卡器进入13扇区通过校验算法校验金额部分数据的真实性,若通过校验,则将读卡机设置的消费金额与已存在数据运算,同时传输消费金额给数据库去运算,因此我们可以使用重放攻击来篡改金额消费。将我的卡内余额150元时的13扇区数据保存下来,等到卡内只剩50元时重新写入回去,此时在卡机上读取到的余额为150元,但服务器端数据库中的实际值只有50元,此时消费10元,读卡器会直接运算150-10=140元后写入卡,同时将10元的消费记录通过内网传送给数据库,数据库运算后余额为40元然后保存。尽管卡中余额与数据库中的余额不相同,但仍然可以消费不会被拉黑。充值饭卡的过程中会进行实时核验,如果卡的金额被篡改过,充值后金额会与数据库中金额对应不上,就会直接在数据库中把该卡对应的UID去除,之后刷卡就会读卡失败。

消费10元

图书馆管理系统同样联网,但相比饭卡管理安全性更差,门禁和借还书均不验证发卡号,只验证卡片对应UID,知道别人卡片的UID号即可冒充别人出入图书馆,这种也是社区门禁最常用的验证方式。即使不知道卡片UID号,我们可以在借书机前用手机NFC修改卡片的UID号,若该UID在系统中存在,就能通过验证并将学号和姓名显示出来,如图所示。我在自己UID号的基础上修改第一位数字,8次尝试中成功识别出来了4个同学的身份信息,由于借书使用的密码是出生年月日,我们可以根据已经获取的学号姓名在学校的QQ群中查找到其社交帐号,并根据社交帐号的信息确定其出生年月日,这样我们就利用社会工程学的方法获取了他人的借书密码,从而冒用他人信息借书。

    

M1卡技术的安全漏洞早在08年已被公布,但时至今日仍然有大量的酒店门禁卡、校企一卡通使用这种老旧技术,很容易被破解造成经济损失。我校一卡通使用了M1 4K容量卡,相对1K容量卡较为少见,需使用Proxmark3方可破解,而很多地方的RFID系统用的是1K容量的卡,针对这种卡的破解方案太多了,绝大多数使用百元的设备即可破解。有能力是用CPU卡设备的需要尽快更新设备,有些地方因为设备较多,老用户基数较大的情况不能立马使用新设备的要加强管理,例如我校的一卡通除了饭卡扇区使用一卡一密外,其他扇区均使用了统一的密钥,如果有人将统一的密钥泄漏出去,那么其他人使用手机NFC通过该密钥读取水卡扇区,篡改水卡金额,几乎没有任何成本。另外我校的自动贩卖机会显示消费验证身份时使用的发卡编号,这就存在着冒充别人身份消费的风险,特别是很多卡机附近没有监控,一旦出现这种情况,就很难找到直接责任人。

转载自原文链接, 如需删除请联系管理员。

原文链接:一卡通(M1卡)破解过程记录——数据分析(水卡、饭卡及门禁),转载请注明来源!

0