作者:erase 提交日期:2007-12-20 14:58:00
原始地址:
http://www.tianya.cn/New/PublicForum/Content.asp?
idWriter=5696620&Key=531752475&strItem=free&idArticle=1076923&flag=1
从银行ATM的技术角度看许霆案-银行是故意的吗?
刚看到这案子的时候除了觉得许霆很冤外,同时觉得很蹊跷,至少【公开的报道的事实】有很多经不起推敲的地方。
本人以前做过MIS系统个开发和测试,也做过软件硬件的系统集成,不过那是很久前的事情了,也没有涉及到金融系统,所以如果本文有什么问题,请达人指正。
废话少说:
先描述一下我对ATM提款所涉及到的系统硬件、软件的理解:
登陆过程:
ATM接收提款人的身份验证信息(卡+ 密码)-》身份验证信息提交银联网络-》身份验证信息数据提交卡所在银行数据服务器-》卡所在银行数据服务器验证身份信息-》验证结果提交银联网络-》验证结果提交ATM机
登陆成功后ATM机进入操作菜单界面
取款过程:
ATM机 银联网络 卡所在银行数据服务器
输入取款金额
|
验证金额数据合法性(注1)
|
【金额数据】 -》 【金额数据】 -》 【金额数据】
|
验证金额数据合法性(注2)
|
【准予操作】 《- 【准予操作】 《- 如验证数据合法,则【准予操作】
|
吐出纸币
|
生成【操作记录】 -》【操作记录】 -》 【操作记录】
保存操作记录,并从卡中扣除金额
(注1)是否为50或100倍数,是否超过每次提款上限
(注2)是否超过卡中余额,是否超过每次提款上限,是否超过日提款上限,是否超过日提款次数
需要说明的是,ATM机所在的银行并不一定是卡所属的银行,本人目前不知道ATM机所在银行和和卡所属银行究竟是哪些银行。
问题:究竟在什么时候1000变成了1?
推测1:卡所在银行的服务器在保存交易记录时1000变成了1
推测2:ATM将输入的1000变为1然后将1提交给了卡所在银行数据服务器,并且生成的【操作记录】也将吐出的1000记录成1并提交到卡所在银行服务器
推测3:银联网络进行数据处理时将1000变为1
一个小问题需要说明一下,本人认为许霆不可能是输入了1,但ATM吐出了1000,本人没用过广州商业银行的提款机,以在其他银行提款机上的使用经验,许霆如果输入的数字少于50元,应该能够得到类似提示【本提款机只能提供面值50元和100元的人民币,请输入50或100的倍数。。。】,所以许霆输入的不是1元,而应该是1000元。
如果以上的3总推测有1个是正确的,那么本人可以肯定的是,不是ATM机的质量原因或者网络的质量或者是服务器及软件的质量问题引起的,而是人为导致的结果,不管这个人为行为是不是故意的。
相信编过软件和测试过软件的人都清楚,一个隐藏很深的BUG(无论是硬或软的,通常是内存溢出),不可能将1000变为1,因为计算机是2进制的。为什么说是隐藏的很深的BUG呢,那是因为我相信银行的软件及硬件都是经过长时间大负荷地测试联调后才正式上线使用的。那么可能出现的BUG我觉得只是在非常特殊的情况下才出现,象这样连续几个小时都存在的BUG,不能不说非常不可思议。
推测1的解释:
卡所在银行的服务器在保存交易记录时1000变成了1
如果人为地将1000变成1,只需要在程序(一个存储过程)上做小小的改动。可能有人问,为什么卡所在银行的服务器上软件的改动只影响了这一台ATM机呢,那是因为这个ATM向服务器提交数据时同时会告知服务器本ATM机的ID号,在改动程序的时候只需要判断ID号就可以只在这台ATM上实现了。
本人比较相信这种推测:因为实施起来难度较小,至于为什么要这么做,那各位可以去联想。
推测2的解释:
ATM将输入的1000变为1然后将1提交给了卡所在银行数据服务器,并且生成的【操作记录】也将吐出的1000记录成1并提交到卡所在银行服务器。
本人因为没有参与过ATM的开发,所以不知道ATM软件更新的流程是什么。如果仅仅从软件代码的难度上考虑,将ATM机加上一段实现此功能的代码是容易。但是可能碰到的问题是如果卡所在银行限制了每天取款的次数,那么本推测将不成立,因为取款次数高达171次。
推测3的解释
同上,如果卡所在银行限制了每天取款的次数,那么本推测将不成立。银联网络实际上是各银行间进行数据交换的接口,这个接口会将各银行接收到的数据进行格式转换然后转发给其他银行。从技术上讲,修改进行格式转换的代码也有可能达到此目的。
匆匆写就,达人指正。
=================================================================
jolestar 注: 觉得这个分析很有意思,本人没有开发过类似程序,所以不好评论。这里有没有达人能给解释一下?
分享到:
相关推荐
在2007年的许霆案与汇丰银行的案例对比中,可以看到不同国家和地区对于此类事件的法律和道德判断存在差异。汇丰银行在某次事件中选择不追究客户因ATM机故障多取的现金,而在其他情况下,如英国的朱伯特家族和Joanne ...
* 许霆信用卡取款案:许霆使用信用卡在ATM机上取款,但由于银行卡账户里的金额异常,让他连续取款5.4万元,后经警方查实,许霆先后取款171笔,合计17.5万元。 电子商务法概述教学课件汇总整本书电子讲义全套教学...
然而,近年来,随着一些社会关注案件的曝光,如许霆案,提出了刑罚对构成要件的反向制约作用,即"以刑制罪"的现象。这种观点认为,刑罚的设定可以在一定程度上影响对犯罪构成要件的理解和应用。 "以刑释罪"可被归类...
在讲授新课阶段,学生分享调查结果,分类和讨论不同类型的诱惑,然后通过具体案例(如许霆恶意取款案)探讨金钱诱惑的影响,引导学生思考如何在诱惑面前保持道德底线。 7. **教学反思**:教学过程中,教师应关注...
车牌识别项目
python、yolo
Ollama本地模型对话、选择本地文件、本地图像对话 1、新增根据聊天记录回复的功能。 2、优化了部分ViewModel,将对应Model字段、属性移到Model中,方便后续扩展。 3、新增读取外部数据回复问题功能,目前支持txt文件。 4、新增添加图片提问题功能,模型需要支持视觉(如:minicpm-v:latest)。 5、优化了类结构,创建对应的Model(MainWindowModel),将所有字段、属性移到Model。 6、新增聊天记录窗体,修改了窗体加载时,加载聊天记录的功能。将其拆分成一个视图。 7、移除了折叠栏功能,更新为Grid区域的显示与隐藏。 将聊天记录列表从主窗体中分离)。 8、更新记录文件加载功能,显示提问日期。 新增选择文件类型设置预览图标。 9、新增功能,新聊天后第一次提问完成后,保存的记录刷新到记录列表、记录删除功能。 10、新增功能,创建新窗体判断显示Ollama服务运行状态。
车牌识别项目
人工智能、大语言模型相关学习资料
车牌识别项目
图像处理项目实战
P+F安全栅组态软件
图像处理项目实战
图像处理项目实战
车牌识别项目
COMBAT FURY.7z
车牌识别项目
系统选用B/S模式,后端应用springboot框架,前端应用vue框架, MySQL为后台数据库。 本系统基于java设计的各项功能,数据库服务器端采用了Mysql作为后台数据库,使Web与数据库紧密联系起来。 在设计过程中,充分保证了系统代码的良好可读性、实用性、易扩展性、通用性、便于后期维护、操作方便以及页面简洁等特点。
车牌识别项目
这是第2402节课的内容,作为复习资料