不为人知的地下暗流:揭秘色情推广“影科技”家族背后的流量生意

一、前言

想知道自己为啥话费总是不够用吗?

想知道自己手机为啥莫名的卡顿的吗?

想知道自己手机里面为啥总有那么些不请自来的APP天天见吗? 

这一切的难言之隐的背后绝大多数都来自于 “小电影”的诱惑,近期腾讯反诈骗实验室及移动安全实验室的鉴黄师又发现了一波以心动、裸色等名义进行传播的恶意应用。这款由X影科技开发的虚假色x应用(不要失望,现在要找个良心的真■小电影是非常不容易的,需要丰富的阅历和技巧)仅仅只借这个名义来完成它的发财梦。根据腾讯反诈骗实验室/移动安全实验室/手机管家安全团队的分析,该科技有三个发财套路:

1、快捞一比(先赚一笔保底):本身通过色情内容诱导用户付费,快速捞取一波收入;

2、再推一把(推广费也是必须拿到手的):通过恶意安装推广一批应用来赚取响应的分层收入(比如给你弄个游戏恶意扣费应用,玩把手机分分钟被套路扣钱);

3、最后留一手(持续性牟利):通过ROOT用户手机将自营后门植入用户手机底层(通常具备防卸载功能,篡改系统文件的行为),如此病毒开发商就能持续的通过这个恶意后门给用户推广各种应用达到持续性牟利。

二、病毒简介

1、母包本身多包含恶意行为,如短信扣费、诱导扣费、恶意推广;

2、下载安装的子包申请设备管理器权限防卸载;

3 子包潜藏在系统后台,高频率推广安装各类应用(有大牌正规应用,也有众多急于发家的不良应用);

4 包含Root行为,成功后可静默安装推广应用;

5 检测安全软件并退出。

下面以该家族病毒中用户量较大的一个应用为主展开分析:

应用名:心动影院

包名:com.txy.wzd

证书MD5:96C81FBBA5E*******67E4F587CA9C4

主要推广流程:

主要推广流程 

主要加载流程:

主要加载流程 

近三十天影响趋势:

近三十天影响趋势 

 

三、详细分析

2.1 动态行为及分析

启动之后发现检查更新,并且必须进行更新,抓包获取到了更新的地址为:

 

http://videoapk.ycd****.com/20170802/837c24b8-d9e0-4150-a1fd-5b59034c594d-ishow_v5.3.15_3e360e2_plugin_patch_full.apk

 

动态行为及分析

 

 

更新之后启动的界面如上图右所示,很明显的一个色播类病毒。

 

 

上方送流量点击后跳转至http://liliang.yc****.com/liuliang/index.html#/produce

 

 

通过抓包可以发现应用除了更新、上传信息、下载图片、获取扣费信息等“正常行为”外,还下载了几个可疑的文件:

 

 

http://apk.chao****.cn/e13e432513914cdf9aa75ddb3eaa7adb.apk

 

 

——包名为com.cime.kige

 

 

http://dws.enh.i-bigda***.net:8080/appstore/pri/5403ddd6ecda4977b0ac92526095b12a.apk

 

 

——包名为com.kert.porn

 

 

http://cdn0127.868***.com:8080/edt6_r.apk

 

 

——加密文件

 

 

接下来发现应用执行了这样的命令:

 

 

chmod 777 /data/data/com.txy.wzd/files/arte /data/data/com.txy.wzd/files/arte "0" "/storage/emulated/0/.0ff7ed298509a28/com.kert.porn/abc/com.kert.porn_r1.app" "1800" "com.txy.wzd" "com.kert.porn" "com.auu.aoc.action" "/storage/emulated/0/.fd.lk" "sy" "sy" "p3005" "0" "2" "4"

 

 

里面包含了一个包名com.kert.porn,也就是之前下载下来的apk。

 

 

命令执行的文件arte是个elf文件,使用IDA进行分析:

 

 

文件分析

 

 

主函数处无数的局部变量,对应是打乱了顺序的字串,还原顺序之后就可以发现一些有趣的东西:

 

 

 

am startservice –-user %s -a %s

am start –user %s -a android.intent.action.INSTALL_PACKAGE -file://%s

 

 

 

主函数:

 

 

主函数 

 

 

主函数 

 

 

主函数 

 

 

com.kert.porn(无图标应用):

 

 

无图标应用 

 

 

申请设备管理器权限及安装同类应用(com.moxy.held)。

 

 

申请设备管理器权限及安装同类应用 

 

 

申请设备管理器权限及安装同类应用 

 

 

应用以一个极高的频率(1分钟以内1次,1次5条消息两个应用安装)推广以及弹出安装界面,以及安装桌面图标,同时在运行其他应用时弹出底部弹窗,同时申请了设备管理器权限防止从手机端卸载和停止服务,并且在取消激活设备管理器处弹出恐吓类提示:

 

 

申请设备管理器权限及安装同类应用 

 

 

上面的各种操作里面中抓到的下载相关的包。

 

 

http://dws.enh.i-big****.net:8080/appstore/pri/1727d8d50a5a42dc9af5edd1325864da.apk

 

 

——熟悉的域名,和前面下载com.kert.porn的相同,包名com.moxy.held,应用名Sys safe

 

 

http://cdn0127.86***.com:8080/edt6_r.apk

 

 

——与之前相同

 

 

http://adsoz.syinxxxx.com/appstore/apk/7f23b78694f94347b76723e3cb6549a9.apk

 

 

——推广的应用

 

 

并且动态分析中也发现com.kert.porn执行了如下命令:

 

 

chmod 777 /data/data/com.kert.porn/files/part /data/data/com.kert.porn/files/part "0" "/storage/emulated/0/。86a0497029/com.moxy.held/abc/com.moxy.held_r1.app" "1800" "com.kert.porn" "com.moxy.held" "com.buu.boc.action" "/storage/emulated/0/.fd.lk" "default_hou" "default_hou" "p0000" "0" "1" "1500982411"

 

 

这与前文的命令结构参数相似。

 

 

于是可以有理由地猜测com.kert.porn与com.txy。wzd具有相似的功能,将part这个elf文件拿到IDA里面看了之后也发现与前面分析的arte功能完全相同。

 

 

最后动态把com.moxy.held跑起来,得到了与com.kert.porn同样的效果,包括下载的文件。

 

 

同时从流量角度也可以分析出广告推送和可疑文件下载的大致流程:

 

 

广告推送和可疑文件下载的大致流程 

 

 

动态方面的分析到此结束,下面将会从静态展开更详细的分析,由于模拟器架构问题,其实导致不只一处的功能执行出现问题,这些遗憾将由静态分析来补全。

 

 

2.2 静态详细分析

 

 

静态分析主要关注以下两个个方面:

 

 

1、 子包的加载流程

 

 

2、 各个包的功能

 

2.2.1 子包加载流程分析

 

 

对apk解包之后的文件粗略浏览之后没有发现未加密可以直接加载的文件,那么多半是从服务器获取或者解密本地文件的了,本地文件里面有且仅有一个文件可疑度较高(如下图),同时动态分析中抓到的下载的edt6_r.apk也是一个疑似加密后的文件。

 

 

子包加载流程分析

 

 

字串搜索可以直接搜索到stdata.db,同时定位到具体方法为com.st.m.u.o.b.

 

 

子包加载流程分析 

 

 

简单分析可以得到解密算法如下:

 

 

解密算法 

 

 

解密算法 

 

 

编写脚本将文件解密还原,得到一个apk文件,其包名为mf。ck,同时解包后可以发现其assert文件夹中的一个zip文件解压后正包含arte和liblive.so两个之前发现过的文件。

 

 

对子包进行进一步分析时发现了与母包相似的文件处理:

 

 

与母包相似的文件处理

 

 

与母包相似的文件处理

 

 

简单观察可以发现用于解密的字串为edt6g,于是猜测是用来解密edt6_r.apk的,改改脚本成功跑出来还原后的apk,包名为com.a.a.a.

 

 

回到stdata中继续分析,assert中两个elf文件中的一个:arte的功能前文已经验证过是安装com.kert.porn的了,另一个liblive.so则是一个native库。 

 

 

直接IDA分析,套路和之前arte中见到的一样,打乱字符顺序降低可读性,还原之后在几个函数中发现了一些值得注意的东西:

 

 

1、 Host: so.i-bigdatas.net

 

 

2、 POST / HTTP/1.1

 

 

3、 /files/ensfd/

 

IDA分析

 

 

 IDA分析

 

 

可知其通过HTTP请求获取了一个zip文件。

 

 

从平台上的数据可以看到在POST了so.i-bigdatas。net之后不远处就出现了一个zip文件,并且在加载的子包处也有了ensfd的踪迹:

 

 

IDA分析

 

 

这个子包并没有加密,其包名也为mf.ck.

 

 

至此com.txy.wzd的子包加载流程结束,整理为下图:

 

 

子包加载流程 

 

 

对com.kert.porn进行分析可以得到基本完全一样的结果,仅仅是第一步解密加载的不是stdata.db而是jdta.db,第二步中启动的应用是com.moxy.held这两个区别,其余部分可以说是完全相同;同样的com.moxy.held与com.cime.kige也表现出了同样的特征,后三者的内部结构可以说是完全一样的。

 

 

jdta.db与stdata.db这两者有着不小的区别,具体将在下文分析到,然而在子包的加载这个流程中,表现出的行为是完全相同的。

 

 

下一小节将详细分析各部分都具体做了些什么动作。

 

 

2.2,2 各个母包/子包的功能分析

 

 

先将这一小节将分析的母包/子包进行分类列举:

 

 

1、 com.txy.wzd以及com.kert.porn类(包含com.moxy.held/com.cime.kige)

 

 

2、 mf.ck(stdata.db/jdta.db)

 

 

3、 com.a.a.a(edt6_r.apk)

 

 

4、 mf.ck(mount_x_x.zip)

 

Part1

 

 

首先从母包开始分析,com.txy.wzd作为一个最初的传播个体,也是唯一一个有图标的应用,比较尽职尽责地发挥了自己作为一个色播类应用的功能,诱导扣费、短信暗扣、隐私获取等常规功能一个不落;除此之外就是加载子包了。

 

 

各个母包/子包的功能分析 

 

 

接着是com.kert.porn,应用启动之后第一件事就是检查自己有没有设备管理器权限,如果没有就申请权限,并且设置恐吓提示防止用户取消设备管理器权限,起到对小白用户的防卸载功能。

 

 

各个母包/子包的功能分析 

 

 

各个母包/子包的功能分析 

 

 

各个母包/子包的功能分析 

 

 

(a.Q解密后为“取消激活会引起系统问题,请慎重!”,与动态中一致)

 

 

除此与子包加载的代码之外静态分析发现了一些HTTP下载的代码,不过都没有被执行到,源头处不存在显示调用,同时log中也没有相关记录,初步推测推广行为产生于其子包中。

Part2

 

 

这部分将对stdata.db和jdta.db分别进行分析。

 

 

stdata.db的功能相对简单,主要用于HTTP请求获取edt6_r.apk和com.kert.porn这两个后续加载的包了。

 

 

设置下载的com.kert.porn的存储位置以及移动后的文件名(com.kert.porn_r1。tmp[app]);

 

 

各个母包/子包的功能分析

 

 

请求并下载com.kert.porn

 

 

各个母包/子包的功能分析

 

 

各个母包/子包的功能分析 

 

 

edt6g的文件解密以及加载(v2.a()为解密文件),加载的方法为com.z.x.actor.ASMn.init

 

 

各个母包/子包的功能分析 

 

 

除此之外还带有安全软件的检测功能,这部份数据被传送到云端,并根据送回的数据进行操作,这里检测到之后会直接退出应用。

 

 

各个母包/子包的功能分析

 

 

而jdta.db的功能则比stdata.db要丰富许多,在其母包com.kert.porn仅有一个防卸载功能的情况下,作者将剩余的操作全部放进了这个子包当中,同时还具备了stdata.db的所有功能(下载的应用为com.moxy.held),这也直接导致了这样的情况:

 

 

各个母包/子包的功能分析 

 

 

下面我们对jdta.db中除开stdata.db已有的具体的恶意行为进行分析,从之前的动态结果来看,主要是恶意推广的行为、安装行为以及一个浮动窗,浮动窗在点击之后会弹出类似一个应用商店一样的窗口,那么下面将依次进行分析。

 

 

一切动作都避不开apk的安装(最终目的),那么首先定位到了安装apk的代码如下:

 

 

安装apk的代码 

 

 

然后由此一步步向上回溯便将恶意行为的流程挖掘地差不多了,可以发现有以下几处位置最终调用了这个函数:

 

 

1、 下载com.moxy.held之后

 

 

2、 浮动窗应用商店之中的下载按钮点击后

 

 

各个母包/子包的功能分析 

 

 

各个母包/子包的功能分析 

 

 

3、 shortcut创建时

 

 

各个母包/子包的功能分析 

 

 

(上图onCreate()函数将安装shortcut,com.be.h.a.a()函数内含具体操作,函数结尾处为下图,下图中的类a即为安装行为所在的类)

 

 

各个母包/子包的功能分析 

 

 

通知栏推送以及底部弹窗的相关代码:

 

 

各个母包/子包的功能分析 

 

 

各个母包/子包的功能分析 

 

 

各个母包/子包的功能分析 

 

 

各个母包/子包的功能分析 

 

 

Part3

 

 

edt6_r.apk这个子包在被加载时调用的是其com.z.x.actor.ASMn的init()方法,这个方法内部如下:

 

 

com.z.x.actor.ASMn的init()方法 

 

 

k.b()与j.a()最终都是去打log了,内部有一定的格式处理,关键点应该在下面的ADSUninstallRulesManager。adsRulesGet(arg3)函数中,此处的arg3参数在之前调用的位置可以看到是:

 

 

arg3参数 

 

 

arg3参数 

 

 

b.a(aka.l)也就是com.z.x.actor.ASMn

 

 

这个函数内部是类似添加白名单的机制;然而由于该子包在我的机器以及虚拟机上都无法正常运行,于是无法完全确定其功能,从静态来看,edt6_r.apk整体是一个独立的apk,其功能同样是广告的推送:

 

 

edt6_r.apk整体是一个独立的apk 

 

 

edt6_r.apk整体是一个独立的apk 

 

 

edt6_r.apk整体是一个独立的apk 

 

 

此外未发现其他异常操作。

Part4

 

 

最后是mount_x_x.zip这个包,这个包来自于jdta.db/stdata.db中liblive.so的下载,其包结构中值得注意的部分如下:

 

 

mount_x_x.zip包

 

 

代码中多处出现可疑命令操作:

 

 

代码中多处出现可疑命令操作

 

 

解密出来的一些字串:

 

 

解密出来的一些字串

 

 

解密出来的一些字串

 

 

非常明显的一个Root工具包,同时它还从以下地址下载了Root所需要的文件:

 

 

http://dws.enh.**********.net:8080/tot/dev_tot2

 

 

http://dws.enh.**********.net:8080/tot/sul18

 

 

http://dws.enh.**********.net:8080/tot/base

 

Root工具包

 

 

然后以调用elf文件Matrix开始,进行root。

 

 

Root工具包 

 

 

 

 

 

四、信息分析

 

 

从上述的分析中,我们可以提炼出一些信息如下:

 

 

1、 QQ:5424**237、33778**378

 

 

@QQ信息 

 

 

 

 

 

2、 银行信息

 

 

银行信息 

 

 

3.1 溯源

 

 

QQ号未能发现任何有价值的信息,银行的信息可以定位到如下内容:

 

 

银行信息定位

 

 

URL中,信息相对有效的如下:

 

 

有效信息

 

 

信息指向杭州*影科技有限公司。

 

 

信息指向杭州*影科技有限公司 

 

 

信息指向杭州*影科技有限公司 

 

 

此家族的恶意软件可基本认为为该公司开发制作。

 

 

3.2 apk推广分析

 

 

推广的apk全部下载自以下两个网址:

 

 

http://adsoz.*******.com/appstore/apk/

 

 

http://apk.**********.cn/

 

其中前者下载的apk多为灰色应用,且具有高度的不规则性(色播、游戏暗扣、盗号类,种类繁多),同时网址下还包含一部分常规应用。

 

 

推广应用类型 

 

 

推广的恶意应用中用户量top10:

 

 

推广的恶意应用中用户量top10 

 

 

后者为com.txy.wzd内置的广告点击后下载apk的域名,这部分域名下数据较少。

 

 

这些apk同样大部分为灰色/病毒应用,值得注意的是其中还包含了一些同家族的应用(具有相同的结构,如stdata.db的存在)。

 

 

对com.txy.wzd所涉及到的域名下的apk进行收集整理:

 

 

1、 zqbs.*******keji.com:

 

 

对com.txy.wzd所涉及到的域名下的apk进行收集整理 

 

 

样本量较少,但高度统一,分析后确认全为com.txy.wzd的同家族应用。

 

 

2、 m.***apps.net:

 

 

对com.txy.wzd所涉及到的域名下的apk进行收集整理 

 

 

对同包名和同应用名去重后,其中大部分应用为com.txy.wzd同家族应用,包名mf。ck应用名enh的为之前分析过的mount_x_x.zip即为Root子包;且包含一些行为相似的应用(疑似另一家族)以及shopapp这个行为均不同的应用。

 

 

3、 air.*****datas.com

 

 

该域名下绝大部分与***apps.net一致,多出的少数应用中的大部分与***apps.net的另一家族应用同样具有恶意行为,个别应用具有其他恶意行为。

 

 

新发现的疑似同家族应用有:

 

 

疑似同家族应用有 

 

 

(gtc init及其包名应为随机生成,上面各图中类似的英文名应用均表现一致)

 

 

shopapps这个应用表现出的特征与下列几个应用一致,这几个是与com.kert.porn同证书且表现不同的子包。

 

 

不同的子包

 

 

五、清理方案

目前,腾讯手机管家安全专家针对该病毒提供了以下卸载方案:

 

 

卸载 

 

 

1、 卸载相关应用(如有设备管理器权限先取消)

 

 

2、 清理下载的各类应用以及创建的文件

 

 

相关文件夹如下:

 

 

/storage/emulated/0/sy开头的所有文件夹

 

 

/storage/emulated/0/SAdAssertsAX

 

 

/storage/emulated/0/。s_d_p

 

 

/storage/emulated/0/。[字母数字乱码](com.kert.porn下载apk全部位于此处)

 

3、 清理系统中被替换的的恶意文件

 

 

debuggerd

 

 

pidof

 

4、 若清理失败,可尝试双清恢复出厂设置或刷机解决。

转载于:https://www.cnblogs.com/h2zZhou/p/7337460.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
1JAVA SE 1.1深入JAVA API 1.1.1Lang包 1.1.1.1String类和StringBuffer类 位于java.lang包中,这个包中的类使用时不用导入 String类一旦初始化就不可以改变,而stringbuffer则可以。它用于封装内容可变的字符串。它可以使用tostring()转换成string字符串。 String x=”a”+4+”c”编译时等效于String x=new StringBuffer().append(“a”).append(4).append(“c”).toString(); 字符串常量是一种特殊的匿名对象,String s1=”hello”;String s2=”hello”;则s1==s2;因为他们指向同一个匿名对象。 如果String s1=new String(“hello”);String s2=new String(“hello”);则s1!=s2; /*逐行读取键盘输入,直到输入为“bye”时,结束程序 注:对于回车换行,在windows下面,有'\r'和'\n'两个,而unix下面只有'\n',但是写程序的时候都要把他区分开*/ public class readline { public static void main(String args[]) { String strInfo=null; int pos=0; byte[] buf=new byte[1024];//定义一个数组,存放换行前的各个字符 int ch=0; //存放读入的字符 system.out.println(“Please input a string:”); while(true) { try { ch=System.in.read(); //该方法每次读入一个字节的内容到ch变量中。 } catch(Exception e) { } switch(ch) { case '\r': //回车时,不进行处理 break; case '\n': //换行时,将数组总的内容放进字符串中 strInfo=new String(buf,0,pos); //该方法将数组中从第0个开始,到第pos个结束存入字符串。 if(strInfo.equals("bye")) //如果该字符串内容为bye,则退出程序。 { return; } else //如果不为bye,则输出,并且竟pos置为0,准备下次存入。 { System.out.println(strInfo); pos=0; break; } default: buf[pos++]=(byte)ch; //如果不是回车,换行,则将读取的数据存入数组中。 } } } } String类的常用成员方法 1、构造方法: String(byte[] byte,int offset,int length);这个在上面已经用到。 2、equalsIgnoreCase:忽略大小写的比较,上例中如果您输入的是BYE,则不会退出,因为大小写不同,但是如果使用这个方法,则会退出。 3、indexOf(int ch);返回字符ch在字符串中首次出现的位置 4、substring(int benginIndex); 5、substring(int beginIndex,int endIndex); 返回字符串的子字符串,4返回从benginindex位置开始到结束的子字符串,5返回beginindex和endindex-1之间的子字符串。 基本数据类型包装类的作用是:将基本的数据类型包装成对象。因为有些方法不可以直接处理基本数据类型,只能处理对象,例如vector的add方法,参数就只能是对象。这时就需要使用他们的包装类将他们包装成对象。 例:在屏幕上打印出一个*组成的矩形,矩形的宽度和高度通过启动程序时传递给main()方法的参数指定。 public class testInteger { public static void main(String[] args) //main()的参数是string类型的数组,用来做为长,宽时,要转换成整型。 { int w=new Integer(args[0]).intValue(); int h=Integer.parseInt(args[1]); //int h=Integer.valueOf(args[1]).intValue(); //以上为三种将字符串转换成整形的方法。 for(int i=0;i<h;i++) { StringBuffer sb=new StringBuffer(); //使用stringbuffer,是因为它是可追加的。 for(int j=0;j<w;j++) { sb.append('*'); } System.out.println(sb.toString()); //在打印之前,要将stringbuffer转化为string类型。 } } } 比较下面两段代码的执行效率: (1)String sb=new String(); For(int j=0;j<w;j++) { Sb=sb+’*’; } (2) StringBuffer sb=new StringBuffer(); For(int j=0;j<w;j++) { Sb.append(‘*’); } (1)和(2)在运行结果上相同,但效率相差很多。 (1)在每一次循环中,都要先将string类型转换为stringbuffer类型,然后将‘*’追加进去,然后再调用tostring()方法,转换为string类型,效率很低。 (2)在没次循环中,都只是调用原来的那个stringbuffer对象,没有创建新的对象,所以效率比较高。 1.1.1.2System类与Runtime类 由于java不支持全局函数和全局变量,所以java设计者将一些与系统相关的重要函数和变量放在system类中。 我们不能直接创建runtime的实例,只能通过runtime.getruntime()静态方法来获得。 编程实例:在java程序中启动一个windows记事本程序的运行实例,并在该运行实例中打开该运行程序的源文件,启动的记事本程序5秒后关闭。 public class Property { public static void main(String[] args) { Process p=null; //java虚拟机启动的进程。 try { p=Runtime.getRuntime().exec("notepad.exe Property.java"); //启动记事本并且打开源文件。 Thread.sleep(5000); //持续5秒 p.destroy(); //关闭该进程 } catch(Exception ex) { ex.printStackTrace(); } } } 1.1.1.3Java语言中两种异常的差别 Java提供了两类主要的异常:runtime exception和checked exception。所有的checked exception是从java.lang.Exception类衍生出来的,而runtime exception则是从java.lang.RuntimeException或java.lang.Error类衍生出来的。    它们的不同之处表现在两方面:机制上和逻辑上。    一、机制上    它们在机制上的不同表现在两点:1.如何定义方法;2. 如何处理抛出的异常。请看下面CheckedException的定义:    public class CheckedException extends Exception    {    public CheckedException() {}    public CheckedException( String message )    {    super( message );    }    }    以及一个使用exception的例子:    public class ExceptionalClass    {    public void method1()    throws CheckedException    {     // ... throw new CheckedException( “...出错了“ );    }    public void method2( String arg )    {     if( arg == null )     {      throw new NullPointerException( “method2的参数arg是null!” );     }    }    public void method3() throws CheckedException    {     method1();    }    }    你可能已经注意到了,两个方法method1()和method2()都会抛出exception,可是只有method1()做了声明。另外,method3()本身并不会抛出exception,可是它却声明会抛出CheckedException。在向你解释之前,让我们先来看看这个类的main()方法:    public static void main( String[] args )    {    ExceptionalClass example = new ExceptionalClass();    try    {    example.method1();    example.method3();    }    catch( CheckedException ex ) { } example.method2( null );    }    在main()方法中,如果要调用method1(),你必须把这个调用放在try/catch程序块当中,因为它会抛出Checked exception。    相比之下,当你调用method2()时,则不需要把它放在try/catch程序块当中,因为它会抛出的exception不是checked exception,而是runtime exception。会抛出runtime exception的方法在定义时不必声明它会抛出exception。    现在,让我们再来看看method3()。它调用了method1()却没有把这个调用放在try/catch程序块当中。它是通过声明它会抛出method1()会抛出的exception来避免这样做的。它没有捕获这个exception,而是把它传递下去。实际上main()方法也可以这样做,通过声明它会抛出Checked exception来避免使用try/catch程序块(当然我们反对这种做法)。    小结一下:    * Runtime exceptions:    在定义方法时不需要声明会抛出runtime exception;    在调用这个方法时不需要捕获这个runtime exception;    runtime exception是从java.lang.RuntimeException或java.lang.Error类衍生出来的。    * Checked exceptions:    定义方法时必须声明所有可能会抛出的checked exception;    在调用这个方法时,必须捕获它的checked exception,不然就得把它的exception传递下去;    checked exception是从java.lang.Exception类衍生出来的。    二、逻辑上    从逻辑的角度来说,checked exceptions和runtime exception是有不同的使用目的的。checked exception用来指示一种调用方能够直接处理的异常情况。而runtime exception则用来指示一种调用方本身无法处理或恢复的程序错误。    checked exception迫使你捕获它并处理这种异常情况。以java.net.URL类的构建器(constructor)为例,它的每一个构建器都会抛出MalformedURLException。MalformedURLException就是一种checked exception。设想一下,你有一个简单的程序,用来提示用户输入一个URL,然后通过这个URL去下载一个网页。如果用户输入的URL有错误,构建器就会抛出一个exception。既然这个exception是checked exception,你的程序就可以捕获它并正确处理:比如说提示用户重新输入。 

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值