大家都知道,传统遥控钥匙很容易被偷车贼破解,用信号干扰车主锁门。 但由于传统钥匙需要把钥匙插进钥匙孔才能发动车,所以一般就算是车门打开了,盗贼也就只能偷偷车里的东西,并不能把车开走。 后来,科技进步了,出现了智能钥匙(smart key),不需要遥控,只要靠近车身一米内,就可以直接开锁。该系统一秒钟之内密码会变化若干次,完全没有破解的可能。 所以,无钥匙进入系统的安全性一度被神话了。 实际上从2016年开始,一种全新的针对无钥匙进入系统的犯罪方式开始出现。这种方式被称为“接力攻击(Relay Attack)”,最早出现在德国。其原理并不是破解密码,而是远距离传输密码从而欺骗车上的解码识别系统。 这种新型盗车模式需要两名罪犯合作,其中罪犯A身上携带解码感应设备靠近车主,而罪犯B则携带另一台设备站在目标车辆的车门边上。当车主下车后,罪犯A就可以跟踪并靠近车主,其身上携带的解码设备会采集车钥匙发射的数字密码,然后传输给守在车边的罪犯B,这个时候车上的解码系统就会误以为罪犯B身上携带的解码感应设备是“车钥匙”,罪犯B从而可以轻松开启车门。 而且由于是智能钥匙,不需要实体钥匙启动,只要有信号,罪犯B就可以把车开走。 针对这种全新的犯罪方式,有人发明了一个可屏蔽钥匙信号的小袋子,其屏蔽原理和物理学中的“法拉第笼子”如出一辙,所以也叫“法拉第袋子(Faraday pounch)”。 不过怎么看这种招数都有一点怪怪的感觉——锁车之后把钥匙塞进小袋子,用车的时候再拿出来,贼是防了,但如此一来无钥匙进入的便利性也就没有了……而且也保不齐车主有忘了把车钥匙塞进小袋子的时候…… 但近日发生在多伦多一位华裔车主身上的事,证明了就算有了法拉第袋子,也阻止不了自己的车被偷,因为盗贼们又有了新招数! 华人车主Mark Liu表示,自己的雷克萨斯(Lexus)SUV在家门口车道竟然被偷走了,而钥匙还安然地在自己手里。 白天雷克萨斯经销商还给他免费换了机油,结果当天晚上这辆SUV就被偷走了。 “我根本不知道这是怎么回事,没有非法闯入的痕迹,他们竟然可以堂而皇之把我的车偷走了”,Mark Liu说道。 Liu怀疑爱车被盗可能与经销商有关,是因为他早已听说过有针对雷克萨斯的盗窃案,也为此采取了防范措施,将车匙特意放在法拉第袋子里。 而Liu邻居的监控摄像头显示,那偷车的盗贼,就是只用了不到3分钟,就把车门打开并且启动引擎将车开走。这样的情形,似乎唯一的解释就是,雷克萨斯车行中出现内鬼,向偷车集团提供了拷贝钥匙,让盗贼轻易得手。 更令人郁闷的是,他和Lexus经销商联系的时候,对方说可以再卖给他一辆……这更加加重了他的怀疑…… 据早前报道,去年11月,多伦多男子Lee Wellbanks的Lexus SUV接连被盗了三次,第一次被盗后,他买了第二辆Lexus SUV,结果第二辆也被盗了。第三辆又被盗后,是警方将车找了回来。Wellbanks称,“盗车贼能启动车子的电脑系统,几秒钟就能把车开走。” 渥太华Gail Downey更不幸,他停在自家车道上的两辆雷克萨斯居然同时被偷。另一位Marnie Bennett运气好一些,她的雷克萨斯8月被盗后,被警方在蒙特利尔找到。 为了防止再次被盗,Bennett不得不给自己的爱车方向盘上上了锁。 大家也不要觉得,只有雷克萨斯会被偷,自己只要不买雷克萨斯就安全了,其实这种新型犯罪会发生在所有采用了同类技术的车上,只是雷克萨斯刚好是偷车贼比较热衷的目标而已。 据CBC报道,去年8月下旬,住在多伦多Danforth地区的Sean Panchal和他的妻子刚刚进家门安顿下来,把新生儿送到床上,窗帘外射进一道车头灯的光。 开始,他们以为这可能是另一辆汽车经过。后来才发现有人跳进他们的丰田RAV4,并将它开走了。 视频可见,偷车贼先是拿着一个用来放大遥控车钥匙信号的装置,把它放在家门口,然后走向车道去偷走停着的车。 有关专家分析,大多数人会将遥控车匙放在他们家的前门附近,而车辆则停在车道上。这样即便罪犯不靠近车主,也能获取信号,传递给自己的同伙。 据悉,一些汽车制造商正在努力修复这个漏洞,但在漏洞修复之前,车主还是要通过各种方式保护自己的车。 首先,不要把车钥匙放在离家门太近的地方。如果住在house里,最好把车钥匙放在二楼,反正越远越好。 其次,虽然有Liu的例子,但毕竟是个例,钥匙最好还是放在屏蔽信号的法拉第袋子里,而不是单独放在外面。 总之,以后一定要提高警惕了! 别掉以轻心,停在家门口也可能不安全啊~最安全的方法,就是把汽车停在车库里,至少要停在照明灯光明亮的地方,让盗贼有所顾忌。 |
Copyright © 1999 - 2024 by Sinoquebec Media Inc. All Rights Reserved 未经许可不得摘抄 | GMT-5, 2024-11-21 22:46 , Processed in 0.136816 second(s), 23 queries .