搬动末端仍是插足了大部分东谈主日常糊口的方方面面， 如酬酢、文娱、购物、出行、搬动办公、汉典医疗等， 苟简了东谈主们的责任和糊口， 促进了社会的杰出. 把柄GSMA及时智能数据分析[1]， 截止到2021年4月， 环球总东谈主口约为78亿， 约有51亿东谈主领有搬动末端. 大部分搬动末端基于Android系统国内破处， 该系统功能刚毅且易于使用， 给东谈主们带来了很大的便利. 但Android系统在给东谈主们带来便利的同期也带来了安全隐患.谷歌公司每年都会发现并建设数百个Android系统上的漏洞， 但仍有大都的零日漏洞存在， 这些漏洞可能会被坏心软件行使， 给社会带来弘远的经济耗损. 把柄IDC预测[2]， 到2023年时， 环球安全软硬件问题导致的开支将达到1 512亿好意思元.
对搬动末端进行的盘曲有极端一部分是为了窃取用户的信息， 而获取用户的口令是一种有用的窃取用户信息的道路. 从用户输进口令到完成认证需要经过数个身手: 用户与末端交互、应用处理、操作系统处理， 其中的每个身手都可能被盘曲. 举例: 在用户与末端交互时， 盘曲者可借助各式传感器开辟获取并行使东谈主机交换过程中产生的光学、声学等侧信谈信息， 以推断用户输入的口令[3−7]; 为了取得方针应用的用户口令， 盘曲者和会过伪造感意思的方针应用[8， 9]或删改方针应用并注入坏心代码[10]等方式， 用户在此类应用中输进口令时， 口令会被窃取; 由于应用运行在系统中， 系统存在的设想漏洞[11−14]可能会导致口令被坏心应用截获. 其中， 针对东谈主机交互过程中基于侧信谈信息的口令推测盘曲时候需依赖于信号质地及口令推测的成功概率， 盘曲者在多个候选的口令围聚中采用进行考证时， 也可能会触发登录抛弃， 盘曲具有一定的局限性. 针对感意思方针应用的口令窃取盘曲需要对具体方针应用定制盘曲战略， 盘曲的普适性较差. 而基于系统设想漏洞的口令盘曲时候适用面较广， 挟制性更大， 受到磋议东谈主员的等闲温情.
本文通过对Android Toast机制的分析， 发现Toast在不需要任何权限的前提下， 可覆盖在其他应用的表层， 且不触发任何系统告诫. 针对Toast的这种设想特点， 本文联接无侵犯就业设想了一种基于Toast重复绘图机制的新式口令盘曲， 竣事快速、隐蔽地获取用户口令输入. 在检测到用户点击方针应用的口令输入框时， 咱们的坏心范例将构造一个定制的Toast垂钓键盘视图， 并通过接续重复绘图该Toast视图， 达到垂钓键盘万古分驻留屏幕并覆盖信得过键盘的恶果. 通过对Android源码分析与用户实验测试， 优化绘图战略使用户无法察觉到垂钓键盘， 进步了该盘曲的隐蔽性. 在此基础上， 本文行使Java反射时候绕过Android系统对Toast类中受限成员变量的探听规章， 竣事了对Toast视图属性的修改， 使坏心应用所创建的Toast芜俚阻拦用户点击事件， 从而有用地获取用户口令输入. 本文针对Android系统版块10及之前的版块有用. 谷歌公司在Android系统版块11中建设了该漏洞， 使盘曲者无法再通过Java反射时候设立Toast阻拦用户点击事件. Wang等东谈主[15]详尽行使Toast和Overlay可对Android系统版块11以及之后版块进行盘曲， 和本文盘曲机制相异.
本文的主要孝顺转头如下:
(1) 发现了Toast机制设想上的安全漏洞. 针对Android系统Toast机制进行分析， 发现Toast绘图和殉难时存在弹出和淡搬动画， 通过重复绘图的要领芜俚使Toast万古分驻留在屏幕上， 并覆盖在其他应用表层， 在此过程中不需要任何权限， 且不触发任何系统告诫;
(2) 建议了新式的口令盘曲时候. 分析Android源码并发现: 可行使Java反射时候修改受限变量， 使Toast可阻拦用户点击事件. 在此基础上， 本文行使Toast重复绘图机制， 联接无侵犯就业设想新式口令盘曲时候， 成功地竣事了在用户无法察觉的情况下对用户口令进行窃取;
(3) 在施行环境中进行盘曲考证明验. 本文领先通过施行Android应用考证盘曲的有用性; 然后， 设想用户实验对盘曲的成功率和隐蔽性进行测试. 实验抛弃标明: 本文所设想的新式口令盘曲具有较高的成功率， 即使口令长度为12位时， 盘曲成功率仍有84.5%. 除此除外， 盘曲具有邃密的隐蔽性.
本文第1节主要先容Toast机制和无侵犯就业. 第2节描写基于Toast重复绘图机制的口令盘曲基本念念想. 第3节先容盘曲的具体责任经过. 第4节对基于Toast重复绘图机制口令盘曲的有用性、准确性和隐蔽性进行实验分析. 第5节先容有关责任. 第6节是转头以及对异日责任的预测.
1 配景本节主要先容Android系统的Toast机制和无侵犯就业功能. 领先先容Toast机制的见地和Toast的责任经过， 然后先容无侵犯就业的见地和功能.
1.1 Toast机制Toast是Android系统提供的弹出音信领导框， 以竣事对用户的快捷反馈， 其弹出时可覆盖于其他应用上方， 并装束部分屏幕内容， 但不会拿获用户对屏幕的点击. Toast责任经过如图 1所示. 本文将Toast音信领导框简称为Toast. 为了在屏幕上显现一个Toast， 需先构建一个Toast对象， 并调用它的show(·)要领. 当Toast的show(·)要领被调用时， 应用领先获取一个NotificationManager对象， 并调用其enqueueToast(·)要领， 将要显现的视图传递给音信料理器(NotificationManager). 终末， 通过跨进度通讯， 将该视图传递给窗口料理器(WindowManager)， 并弹出Toast向用户展示音信， Toast会在显现2 s或3.5 s后肃清.
图 1 Toast责任经过
Toast除了芜俚显现翰墨领导外， 也可显现自界说视图.开发者通过Toast类静态要领Toast.makeText (context， text， duration)来创建一个Toast对象. 设立参数text可设定Toast中需显现的内容， 设立参数duration可修改Toast在屏幕上的显现时分， 该参数只须两种取值: LENGTH_LONG或者LENGTH_SHORT， 分别对应的显现时分为3.5 s或2 s. 图 2(a)是一个毛糙的例子， 通过编程在屏幕上弹出一个Toast， 领导用户: “这是一个Toast”. 此外， Toast类也提供了setView(·)要领可设立自界说的视图(view)， 如图 2(b)所示.
图 2 弹出Toast示例
当Toast的显现捏续时分达到设定的时分后， 音信料理器会调用removeView(·)要领见告窗口料理器， 将Toast从屏幕上移除. 此时， 窗口料理器会启动一个捏续时分为500 ms的淡搬动画， 将Toast透明度巩固降至0. 在淡搬动画捏续的过程中， 透明度的裁延缓度由慢至快， Toast跟着动画巩固退出屏幕. 在removeView(·)要领被调用后， 即动画捏续过程中， 若恭候队伍中存鄙人一个待显现的Toast对象， 则系统将显现新的Toast， 新的Toast会顺利覆盖于前一个正在扩充淡搬动画Toast的表层.
1.2 无侵犯就业无侵犯就业是Android设想用来匡助裂缝东谈主士使用Android开辟的一种料理有规画， 它不错匡助视觉、听觉、举止侵犯东谈主群苟简地使用Android开辟. Android系统提供了几许个官方预装的无侵犯就业应用， 如读屏应用TalkBack， 用户使用TalkBack时无需提神屏幕， 仅需要使用手指触摸刻下屏幕中显现的应用视图或翰墨即可听到语音反馈. 此外， 开发者不错使用Android提供的无侵犯就业API创建和发布自界说的无侵犯应用. 无侵犯应用领有比普通应用更高的权限， 而更高的权限时时意味着更有可能出现安全问题[12， 16， 17].
当无侵犯就业被启用后， 用户和搬动末端的交互过程会产生无侵犯事件， 如点击事件、焦点变化事件等.每个无侵犯事件包含事件产生的时分、事件对应的应用、事件对应的控件节点ID等信息. 无侵犯就业应用芜俚监听和处理系统中的无侵犯事件， 通过无侵犯事件对应的控件节点ID， 应用不错取得无侵犯事件所对应视图的信息， 如当无侵犯事件发生于文本框时， 无侵犯应用可获取刻下文本框中的内容. 同期， 无侵犯应用还不错通过控件节点对用户界面进行操作， 如设立文本框中的内容、模拟点击按钮等.
2 盘曲概述本节阐述Android口令盘曲的基本念念路. 领先先容针对Android应用口令盘曲要领的挟制模子， 然后分析Toast机制存在的设想谬误， 在此基础上， 先容基于Toast重复绘图口令盘曲的基本念念路.
2.1 挟制模子本文口令盘曲的挟制模子假定如下.
(1) 坏心应用被装置在用户的搬动末端上， 况兼用户为该应用开启无侵犯就业权限. 盘曲者不错将坏心应用伪装成游戏援救应用、跳过告白应用等需要无侵犯就业权限的应用， 提供这些应器具有的基本功能， 以此来诱导用户在应用商场下载坏心应用， 并为坏心应用开启无侵犯就业功能. Diao等东谈主[18]对谷歌应用商店中337款需要无侵犯就业权限的应用进行了考核， 发现杰出半数以上(56.7%)的应用下载量杰出100万. 而把柄Felt等东谈主[19]的调研， 只须约17%的用户会温情应用苦求的具体权限. Fratantonio等东谈主[16]在使用无侵犯就业进行界面劫捏盘曲时也作念了疏浚的假定;
(2) 盘曲者不错事先获取被盘曲应用的部分信息， 如被盘曲应用的包名和输进口令界面上的翰墨. 应用信息不错通过事先分析被盘曲应用的装置包来得到;
(3) 本口令盘曲坏心应用是在用户登录被盘曲应用时， 通过绘图垂钓键盘以骗取用户截获其口令输入， 因此本文假定被盘曲应用在登录时用户需输进口令进行登录.
2.2 基本念念路通过对Toast机制的分析， 咱们发现Toast存在以下特点.
(1) Toast不错覆盖在其他应用的表层， 且不需要任何权限， 不会产生见告告诫;
(2) Toast在绘图时会扩充弹搬动画， 在殉难时会扩充淡搬动画. 这导致在集会绘图两个疏浚Toast时， 前一个还未十足淡出的Toast将被下一个新弹出的Toast迅速覆盖， 给用户形成归拢个Toast万古分停留在屏幕上的假象;
(3) Toast可展示自界说视图.
基于以上Toast的特点， 坏心应用不错通过屡次重复绘图的方式使显现自界说视图的Toast捏续覆盖于其他应用的表层. 此外， 无侵犯就业也为坏心应用提供了监听用户输进口令时分的功能.
通过行使Toast设想上的特点， 本文建议了基于Toast重复绘图机制的口令盘曲时候. 领先假定在被盘曲末端开辟中仍是装置了坏心应用， 当用户点击口令输入框后， 系统键盘会弹出以供用户输进口令. 此时， 坏心应用通过无侵犯就业监听到用户的输入事件， 并重复绘图Toast展示自界说视图， 该视图布局和系统键盘布局疏浚且覆盖在系统键盘上， 并劫捏用户的点击. 默许情况下， Toast无法拿获用户的点击， 但通过对Android源码的分析， 咱们发现使用Java反射时候设立Toast受限属性可使其具备阻拦用户点击事件的功能. 把柄用户点击的坐标不错推断出用户输入的字符. 由于用户的点击事件被阻拦， 事件无法传递给底层信得过的系统键盘， 因此用户的输入无法成功. 为使用户输入成功， 坏心应用不错使用无侵犯就业将Toast截获的对应字符填入被盘曲应用的输入框中， 令用户以为我方在操作信得过系统键盘. 用户输入完成后， 坏心应用即可取得齐备的用户口令.
3 基于Toast重复绘图机制的口令盘曲本节先容基于Toast重复绘图机制的口令盘曲， 领先描写口令盘曲的总体经过， 然后先容行使无侵犯就业进行用户步履监听， 当监听到用户输进口令的事件后， 行使Toast重复绘图的时候进行垂钓键盘的显现， 之后阐述何如行使反射获取用户在垂钓键盘上的点击事件， 终末先容通过用户点击位置对口令进行归附.
3.1 盘曲总体经过如图 3所示， 基于Toast重复绘图机制的口令盘曲不错分为4个身手， 分别为用户步履监听、垂钓键盘显现、用户点击分析、口令归附. 领先对用户步履进行监听， 当监听到用户的口令输入事件后， 坏心应用立即显现垂钓键盘， 然后阻拦用户的点击事件并进行分析. 当检测到用户输入结尾时， 坏心应用对用户口令进行归附， 从而完成扫数这个词口令盘曲.
图 3 基于Toast重复绘图机制的口令盘曲经过
接下来详确先容口令盘曲的这4个身手.
3.2 用户步履监听基于Toast重复绘图机制的口令盘曲领先需要对用户的步履进行监听. 这需要将坏心应用装置在用户的搬动末端上， 并为坏心应用开启无侵犯就业权限. 获取无侵犯就业权限后， 坏心应用就不错监听系统中扫数应用产生的无侵犯事件， 包括要盘曲的应用.
在本文中， 坏心应用主要需要监听用户点击口令框脱手输入的步履， 以此笃定盘曲脱手的时机. 当用户点击口令框准备脱手输入时， 系统会将用户点击事件发送给坏心应用， 事件中包括取得用户点击焦点的视图的类名以及该视图是否为口令框. 如果取得焦点的视图是口令框， 则视图类名为EditText， 此时， 调用无侵犯事件的isPassword(·)要相识复返true. 据此， 坏心应用可判断取得焦点的视图是否为口令框. 如果是口令框， 则脱手显现垂钓键盘， 即脱手口令盘曲.
3.3 垂钓键盘显现当监听到用户脱手进行口令输入后， 坏心应用脱手显现垂钓键盘. 在此过程中， 坏心应用行使Toast重复绘图时候生成和系统键盘布局疏浚的垂钓键盘， 将其覆盖在系统键盘之上， 并阻拦用户的点击. 但使用Toast生成垂钓键盘并阻拦用户点击事件存在3个挑战: 第1个是需要使Toast芜俚拿获用户点击事件， 第2个是何如使Toast万古分地停留并覆盖于系统键盘之上， 第3个是何如把柄不同用户的使用民俗切换垂钓键盘的视图.
3.3.1 用户点击拿获由于默许情况下Toast无法拿获用户的点击事件， 因此需要通过反射来完成拿获用户点击事件的功能. 垂钓键盘最紧要的功能是拿获用户点击事件且不被用户察觉. 为达成不被用户察觉的方针， Toast不错显现和系统键盘疏浚的视图， 并将其覆盖在系统键盘之上. 但默许情况下， Toast无法拿获点击事件， 这时， 当用户点击屏幕时， 该点击会穿过Toast到达系统键盘上并被其拿获. 通过Android源码的分析咱们得知: 显现Toast的视图是存放于Toast类成员变量mTn中的mNextView对象， 但该视图的点击拿获属性存放于mParams对象中， 被系统默许设立为FLAG_NOT_TOUCHABLE[20]， 因此该视图无法拿获点击事件， 具体代码如代码片断1所示.
代码片断1. Toast脱手化的部分代码.
1: final WindowManager.LayoutParams params=mParams;
2: params.type=WindowManager.LayoutParams.TYPE_TOAST;
3: params.setTitle(“Toast”);
4: params.flags=WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON
5: |WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE
6: |WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE;
为了使Toast不错拿获点击事件， 坏心应用不错在Toast脱手化之后、调用show(·)要领之前从头设立mNextView对象属性， 即修改mParams对象的值， 将FLAG_NOT_TOUCHABLE参数去除， 之后， Toast即可拿获点击事件. 但mTn对象和mParams对象在系统代码中均未被public修饰， 坏心应用无法顺利探听这些对象， 并修改其属性. 为此， 坏心应用可行使Java反射机制探听受限的mTn对象， 然后通过mTn对象探听其中的mParams对象并修改其值， 将Toast设立为可拿获用户点击， 具体代码如代码片断2所示.
代码片断2. 使用反射修改Toast属性.
1: Toast toast=new Toast(MainActivity.this);
2: toast.setView(keyboard); //设立垂钓键盘视图
3: Field f=toast.getClass(·).getDeclaredField(“mTN”);
4: f.setAccessible(true); //去除Java对Toast类的mTN成员变量探听规章的检查
5: Object mTn=f.get(toast); //获取toast对象中的mTN对象
6: Field f2=mTn.getClass(·).getDeclaredField(“mParams”); //获取mTn对象的TN类的mParams成员变量
7: f2.setAccessible(true); //去除Java对TN类的mParams成员变量探听规章的检查
8: Object mParams=f2.get(mTn); //获取mTn对象中的mParams对象
9: mParams.flags=WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE; //设立为点击可拿获
10: toast.show(·);
3.3.2 基于Toast重复绘图的垂钓键盘驻留在口令盘曲过程中， 垂钓键盘需要万古分驻留并覆盖于信得过系统键盘之上. 一个Toast最长只可停留3.5 s， 因此咱们使用重复绘图的要领保证垂钓键盘万古分驻留在系统键盘之上. 当坏心应用检测到盘曲完成后， 可将刻下垂钓键盘设立为透明， 形成键盘仍是退出的假象. 接下来将重心先容重复绘图时候的表面基础和竣事要领.
在第1.1节中， 通过实验不雅察Toast存在显现过程的弹搬动画和退出过程的淡搬动画， 两个动画均是对Toast视图透明度变化的诊治. 若重复绘图多个Toast， 在第1个Toast巩固淡出的过程中， 系统会同期将Toast恭候队伍中待显现的下一个Toast快速弹出， 相邻两个Toast在屏幕中存在彼此重复的部分， 用户很难察觉Toast领导框的重复绘图过程， 从而达到了使Toast万古分覆盖在信得过系统键盘上方的方针.
Toast重复绘图时候的具体竣事经过如图 4所示.
图 4 Toast重复绘图经过图
● 身手1. 坏心应用在监听到用户输进口令的无侵犯事件后， 通过Toast.show(·)的要领见告系统的见告料理器来创建一个Toast;
● 身手2. 系统中的见告料理器在继承到坏心应用发起的创建Toast请求后会生成token， 并将其通过enqueueToast(·)要领放入Toast队伍中， 该token将会象征惟一的Toast;
● 身手3. 系统的见告料理器会从队伍中获取一个token， 并见告系统就业中的窗口料理器来将Toast绘图到屏幕上. 窗口料理器一次只会处理一个token， 其他Toast所对应的token将会在队伍中恭候， 以此来保证系统不会同期显现多个Toast[21];
● 身手4. 当Toast的捏续时分达到设定值(即2 s或3.5 s)时， 系统的见告料理器会调用removeView(·)要领见告窗口料理器将Toast从屏幕上移除;
● 身手5. 窗口料理器继承到移除Toast的见告后， 脱手扩充淡搬动画. 在此时代， 如果队伍中仍然有未显现的Toast所对应的token， 窗口料理器将同期扩充下一个Toast的弹搬动画.
坏心应用将以选择的时分D为终止重复身手1−身手5， 以使得Toast万古分驻留在信得过系统键盘上方.
在图 4中， 前后两个Toast消结怨出现之间存在一段时分终止Ta， 在这段时天职， 屏幕上不存在职何Toast， 如果用户在此时点击屏幕， 则坏心应用无法阻拦点击事件. 假定用户输入一次口令所用总时分为Ts， Toast在屏幕上时分为Td， 则切换次数可界说为Ts/(Td+Ta)−1. 用户输入拿获的概率为Toast在屏幕中显现时长与相邻两个Toast弹出时分终止的占比， 即Td/(Td+Ta). 由此不错分析出: 当Td更大时， 切换次数更少， 拿获概率更高.这在第4.3.2节的实验中得到考证， 是以盘曲时， Toast的捏续时分应设立为3.5 s.
在Toast重复绘图的过程中， 坏心应用需要采用合适的时分终止D和Toast创建战略， 以进步Toast万古分驻留的隐蔽性. 由于Android系统会将扫数刻下待显现Toast对应的token放入一个队伍中一一显现， 但归拢时分只可有一个Toast显现在屏幕上， 因此如果时分终止D过短， 坏心应用就会在队伍中短时天职添加过多的token， 即使盘曲结尾后， 用于显现垂钓键盘的Toast仍会束缚地出现， 盘曲就很可能会被用户察觉. 相背， 如果D过长， 两个Toast的显现终止时分过长， 后一个Toast将无法在前一个Toast十足肃清之前显现在屏幕上， 容易被用户察觉. 因此， 需要将时分终止D设为一个稍小于Toast捏续时分的值， 通过设立不同的D值进行盘曲尝试， 咱们最终发现将D设立为3.4 s时盘曲恶果最好.
3.3.3 键盘视图切换垂钓键盘显现需要辩论不同输入类型的切换. 用户的口令可能不仅包括小写字母， 而且包括大写字母、数字等字符. 因此， 坏心应用需要把柄用户的点击将Toast所显现的垂钓键盘的模式进行替换， 以免盘曲被用户察觉. 大多数输入法应用中， 输进口令时， 小写字母与数字位于归拢个类型的视图中， 如图 5左侧所示， 因此无需非凡辩论输入数字的情况. 当用户输入大写字母时， 键盘视图如图 5右侧所示. 在用户点击大小写切换键后， 坏心应用需要将垂钓键盘从小写切换到大写. 在Toast重复绘图的过程中， 坏心应用不错使用setImageBitmap(·)要领修改Toast中显现的内容， 由此不错完成不同输入类型的切换.
图 5 两种键盘视图
除此除外， 部分用户不使用系统默许的输入法， 而是使用第三方输入法， 这就要求坏心应用需要将垂钓键盘的视图显现为对应输入法的视图， 以免盘曲被用户察觉. 通过调用系统接口[22]不错获取用户刻下使用的输入法， 盘曲者将用户常用输入法的键盘视图预置在坏心应用中， 在盘曲脱手时， 坏心应用把柄刻下输入法获取对应的键盘视图并加以显现. 由此， 大部分情况下， 坏心应用都会显现出与用户信得过键盘疏浚的垂钓键盘. 如果用户使用小众输入法， 坏心应用莫得预置该输入法对应的键盘视图， 则采用该机型默许输入法的键盘视图. 如Pixel机型出厂时默许的输入法是Gboard， 如果用户购买开辟后将默许输入法设立为小众输入法， 盘曲时， 坏心应用将生成Gboard所对应的键盘覆盖在小众输入法上. 部分应用为了口令输入安全使用动态布局键盘， 对此需要对相应的应用进行提前分析， 了解其动态布局键盘的视图， 之后对键盘视图进行伪造， 并将其覆盖在信得过键盘之上.
3.4 用户点击处理垂钓键盘显现完成并拿获用户点击后， 需要把柄用户的点击进行处理， 以识别出用户输入的字符. 盘曲时， 垂钓键盘所拿获的点击事件中， 有用信息为用户点击屏幕的坐标， 坏心应用需要把柄用户点击的坐标推断出用户输入的字符. 以Google官方输入法Android Keyboard为例， 输进口令时， 其键盘布局为圭臬的QWERTY键盘与数字0−9的联接. 通过阅读源码[23]以及施行测量可知: 当屏幕宽度为X像素时， 扫数按键宽度与高度见表 1， 由此可策划出每个按键的中心坐标. 当用户点击事件发生时， 领先策划每个按键中心坐标与用户点击坐地点欧拉距离， 然后登第欧拉距离最小值所对应的按键为用户刻下按键.
表 1 键盘内字符的宽高
在获取到用户输入字符后， 坏心应用在被盘曲应用的口令框中需填入相应的用户输入， 以免用户察觉盘曲步履. 由于用户的点击事件被垂钓键盘阻拦， 无法传递到基层的信得过系统键盘， 因此用户点击的字符不会被添加到口令框中， 很可能被用户察觉盘曲步履. 坏心应用在识别出用户点击的字符后， 可行使无侵犯就业提供的performAction(·)要领将用户输入填充至口令框， 从而使用户难以察觉盘曲步履.
3.5 口令归附在监听到用户点击完成按钮后， 将此前获取的输入进行拼接归附出用户口令. 由于在拿获用户点击时， 仍是把柄用户点击坐象征别出用户点击输入的每一个字符， 因此将得到的字符拼接就不错得到用户的口令.但口令归附得到的抛弃并不一定十足准确， 因为两个Toast切换时会存在蓦地的粗疏， 导致屏幕上不存在职何Toast. 如果用户在此时进行输入， 则坏心应用无法阻拦到用户点击， 也就无法获取用户输入的字符， 因此归附的口令中可能会遗漏用户的输入， 在第4.3.2节中将进行实验测试口令归附的成功率.
盘曲视频演示可见https://reurl.cc/WEzEM7. 在视频中， 咱们使用Google Pixel 2机型进行演示， 领先为坏心应用开启无侵犯就业权限， 然后切换到被盘曲应用进行口令输入操作， 此时， 坏心应用运行在系统后台. 在用户脱手进行口令输入时， 所弹出的键盘为坏心应用通过Toast伪造的垂钓键盘. 当用户在被盘曲应用的口令框中输入完了后， 坏心应用和会过Toast将获取到的口令内容进行展示.
4 实验考证本节将在施行环境中评估基于Toast重复绘图机制的口令盘曲时候. 领先， 在多款施行应用中考证盘曲的有用性; 然后设想用户实验测试盘曲的准确性， 获取口令归附成功率等数据; 终末， 通过用户实验来测试盘曲的隐蔽性.
4.1 实验环境为考证盘曲的有用性、准确性和隐蔽性， 本节把柄以上时候开发坏心应用并进行实验. 将所开发的坏心应用装置到搬动末端并启动后， 盘曲范例会在后台监听无侵犯事件， 并在用户脱手输进口令时使用Toast阻拦用户输入， 分析点击坐标， 并将所获口令记载到土产货日记文献中.
在盘曲有用性分析的实验中， 使用的末端型号为Google nexus6p， Android系统版块8， 登第的被盘曲应用为谷歌应用商场中较为流行的5款应用， 分别为Skype、脸书、印象条记、推特、Instagram， 以及两款下载量较大的金融类应用， 分别为好意思国银行和支付宝. 盘曲隐蔽性分析的实验中， 所选用的应用为好意思国银行应用. 在盘曲准确性分析的实验中， 领受的测试应用为本文定制开发的应用， 因为需要将坏心应用得到的口令与用户信得过输入的口令进行对比， 由此判断盘曲是否成功.
盘曲准确性分析和隐蔽性分析实验均为用户实验. 用户实验登第了20名志愿者进行实验， 其中包括3名女性和17名男性， 志愿者年级在22−33岁之间， 平均年级25岁， 其中， 20名志愿者实验使用的末端型号和操作系统版块见表 2.
表 2 实验开辟列表
4.2 盘曲有用性分析
本实验分别测试盘曲在不同应用中的线路. 测试者事先将上文提到的7款测试应用装置到搬动末端上， 装置坏心应用并为其开启无侵犯就业权限. 然后分别掀开这7款测试应用， 操作应用跳转至输进口令界面， 在该界面输入长度为10的口令， 并点击登录按钮. 待7款应用一王人测试完成后， 从测试末端的土产货存储中取出日记文献进行分析. 实验抛弃见表 3.
表 3 测试应用列表
经过分析日记文献发现: 除了需要对支付宝应用定制用户步履监听要领外， 坏心应用对7款应用均可获取用户输入的口令. 在领受默许的坏心软件盘曲时， 咱们发现用户在支付宝中输进口令时莫得记载到任何输入. 其原因是坏心范例通过检测到口令框， 并获取到焦点事件后， 脱手显现Toast进行盘曲， 但支付宝的口令框在获取焦点时并不会发出任何事件， 导致坏心范例无法检测到盘曲发起时机. 对此情况天然无法顺利检测到用户脱手输进口令的算作， 然则时时用户在输进口令前需要输入账号. 在用户输入账号后， 会点击口令框， 此时账号框失去焦点， 口令框取得焦点. 坏心应用天然无法检测到口令框取得焦点的事件， 然则不错检测到账号框失去焦点的事件. 因此不错在账号框失去焦点后， 坏心范例检测刻下界面的根节点是否发生变化， 进而推断出用户是否仍在输进口令的界面， 如果用户仍然停留在输进口令界面， 则可以为用户脱手向口令框中输进口令， 此时不错脱手显现Toast实施盘曲.
由该实验不错得知: 天然在小部分情况下需要针对特定的应用设想特定的盘曲战略， 然则基于Toast重复绘图机制的口令盘曲时候具有较好的有用性.
4.3 盘曲准确性分析本文先容的口令盘曲主若是通过拿获用户的键盘输入来竣事， 是以在盘曲中， 对用户点击事件的拿获率决定着盘曲的成功率. 由前文可知， 盘曲中生成的单个Toast捏续时分(2 s或3.5 s)对用户点击事件拿获率存在影响. 因此在盘曲准确性分析实验中主要包含两个实验， 分别测试在两种Toast捏续时分下用户点击事件的拿获率和在最好的Toast捏续时分下不同长度口令归附的成功率.
4.3.1 点击事件拿获率在本实验中， 分别设立坏心应用构建的单个Toast捏续时分为2 s (LENGTH_SHORT)和3.5 s (LENGTH_ LONG)来测试盘曲中点击事件的拿获率. 志愿者将会在两种条目下分别向测试应用的输入框中输入100个字符来测试其中的点击事件拿获率. 在实验中， 统计Toast拿获到点击事件的次数为Ct， 莫得拿获到点击事件的次数为Cp， 则可得拿获率为Ct/(Ct+Cp).
表 4中的数据显现: 对每个搬动末端， Toast捏续时分越长， 触摸事件的拿获率越高. 由实验数据可知: 由于硬件和系统版块不同， 不同机型的拿获率会有所分离， 但Toast捏续时分为3.5 s时， 一般会比Toast捏续时分为2 s的拿获率更高， 这也与前文的表面相投乎.
表 4 Toast捏续时分和事件拿获率
4.3.2 口令归附成功率
在本实验中， 设立坏心应用构建的单个Toast捏续时分为3.5 s， 每个志愿者在被盘曲应用均分别输入长度为4、6、8、10、12的口令各10个， 口令由大写字母、小写字母、数字构成. 实验抛弃如图 6所示. 不错看出: 跟着口令长度的加多， 盘曲成功率巩固裁减. 这是因为部分情况下， 用户输入时Toast赶巧肃清， 未能拿获用户输入. 但即使在口令长度为12位时， 盘曲成功率仍有84.5%. 这领悟该盘曲具有较好的准确性.
在线自拍在线偷拍视频
图 6 口令长度-盘曲成功率联系
4.4 盘曲隐蔽性分析
咱们进行了两组对真的验以测试盘曲的隐蔽性. 在实验中， 志愿者将会在末端上掀开好意思国银行应用， 输入所给口令， 终末点击登录按钮. 咱们采用了两种场景进行测试: 一种为平方使用场景， 另一种为系统后台运犯罪意应用的场景. 当志愿者在两种场景下完成操作后， 咱们对其进行访谈， 辩论是否不雅察到两种场景下的操作存在互异， 只须又名志愿者反应在操作时末端出现反应滞后的情况. 除此除外， 莫得东谈主不雅察到可疑情况. 由此可知: 该盘曲具有邃密的隐蔽性， 可应用于信得过场景中.
5 有关责任搬动末端的用户在进行口令认证时需要数个身手， 用户一般需要在触摸屏的捏造键盘上进行点击， 按键所对应的字符会被输入到应用的口令框中， 应用由此不错得知用户要输入的口令. 由于应用运行在操作系统上， 操作系统相通不错得知用户的口令. 在用户输进口令的过程中， 盘曲者不错通过以下几种方式进行口令盘曲.
(1) 盘曲用户与搬动末端的交互. Maggi等东谈主[3]初次建议触摸屏的捏造键盘被拍摄后可能导致口令表示， 他们设想的范例不错自动索求视频中包含用户点击屏幕的视频帧， 并通过图像识别算法不错识别出此次点击所对应的字符， 由此不错归附用户输入的口令. Yue等东谈主[4]假定盘曲者不错拍摄用户的输入过程， 在看不到屏幕上任何信息的情况下， 设想多种策划机视觉时候自动地定位用户在屏幕上的点击位置， 接着使用平面映射将屏幕点击位置诊治为捏造键盘的键值， 以获取用户口令. Xu等东谈主[5]建议即使远距离拍摄或光源经过反射， 仍可从视频信息均分析出用户的口令. Zhou等东谈主[6]使用用户解锁开辟时， 手指产生的声学信号来推测用户的图形口令. Aviv等东谈主[7]指出: 用户在输入图形口令后屏幕上会留有污渍， 把柄这些污渍不错推断出用户的图形口令. 盘曲用户与搬动末端的交互大多依靠侧信谈的方式来竣事， 这一般要求盘曲者在物理上接近被盘曲者， 这是一个相比强的盘曲假定. 况兼， 侧信谈盘曲得到的一般不是准确的口令， 而是多个候选口令， 需要经过屡次尝试身手得到准确的口令;
(2) 盘曲方针应用. Jung等东谈主[8]指出: 当用户在伪造的应用中输进口令时， 口令可能会被窃取. 他们领先分析数个银行应用的装置包， 绕过其签名及齐备性考证， 然后修改其字节码以添加坏心代码， 终末进行从头打包和签名， 以竣事对方针应用的坏心删改. Aonzo等东谈主[9]使用应用包名来骗取口令料理器， 误导用户将口令输入到伪造的应用中. Luman等东谈主[10]建议在Virtual App等应用容器中运行应用时， 用户的口令可能会被窃取， 他们通过分析应用商场中的应用后发现， 仍是有部分坏心容器上架到应用商场， 在运行时会窃取用户的口令. Ren等东谈主[24]建议了Android多任务机制存在漏洞， 坏心应用不错通过任务劫捏的方式发起伪装骗取盘曲. Wang等东谈主[17]设想了ActivityHijacker， 使用Activity劫捏盘曲， 并设想机制隐没见告栏见告和近期任务的显现， 以进步盘曲的隐蔽性. 盘曲方针应用一般需要对方针应用进行事先分析， 然后通过伪造应用或是在应用中注入坏心代码的方式来得到用户的口令. 当今， Android应用反调试及反删改时候马上发展， 对这种盘曲方式形成了新的挑战;
(3) 盘曲操作系统. Niemietz等东谈主[12]建议了包括传统Toast盘曲在内的多种针对Android UI的盘曲， 大多数漏洞已被建设. Kraunelis等东谈主[13]初次指出， Android无侵犯就业框架可能被用于伪造盘曲. Kalysch等东谈主[14]发现， Android无侵犯就业可能导致口令表示. 他们发现: 天然无法顺利得到用户口令， 但用户输入确刻下一位短时天职会被无侵犯就业获取， 由此不错推断出齐备的口令. Fratantonio等东谈主[16]使用无侵犯就业和Overlay来进行点击劫捏， 通过同期弹出多个Overlay覆盖于键盘上， 来获取用户输入步履， 从而窃取用户口令. 盘曲操作系搭伙般行使操作系统中的安全问题来设想盘曲. 分析操作系统中的安全问题需要较高的时候门槛， 况兼可能需要一些系统权限. 当今， Android系统对权限的苦求越来越严格， 为竣事这些盘曲带来新的挑战.
6 转头与预测本文主要磋议了Android系统Toast机制在设想逻辑和竣事中存在的安全问题， 并基于该安全问题设想口令盘曲. 通过重复绘图坏心Toast， 使其万古分保捏在出息并覆盖在其他应用之上. 同期， 使用Java反射时候设立Toast对象有关成员变量， 使坏心Toast不错阻拦用户点击， 进而显现垂钓键盘劫捏用户输入. 终末， 合作无侵犯就业完成扫数这个词口令盘曲. 在盘曲设想完成后， 本文设想实验在施行环境中对所设想盘曲进行评估， 实验抛弃标明， 本文建议的盘曲时候具有较好的有用性、准确性和隐蔽性.
本文在基于Toast重复绘图机制的口令盘曲中， 使用Toast来显现垂钓键盘阻拦用户的输入， 在显现垂钓键盘时， 把柄用户刻下输入法生成对应的键盘. 天然芜俚知谈用户使用的输入法类型， 然则无法得知用户民俗使用的键盘布局为9键如故26键， 生成的键盘可能并不是用户平时使用的键位键盘， 即使在这之后不错模拟键盘的操作， 进行有关的切换， 然则警醒的用户可能察觉到设立发生了变换; 当用户自界说键盘皮肤时， 伪造的键盘会与用户设立的皮肤不一致国内破处， 这可能导致盘曲被用户发觉. 在异日的责任中， 不错联接用户的输入法设立文献读取输入法各项设立， 进而生成与用户自界说键盘疏浚的键盘， 进步盘曲的隐蔽性. 且在盘曲中使用了无侵犯就业来监听用户点击口令框的事件， 这是一个较强的盘曲模子， 无侵犯就业所需要的权限与其他权限不同， 需要用户手动授予， 这加多了盘曲实施的难度. 在异日的责任中， 可能辩论以其他方式监听用户点击口令框事件， 以减少盘曲所需要的权限.