TraceDroid动态分析：应对2013年激增的安卓恶意软件

需积分: 9 106 浏览量更新于2024-07-20 收藏 1.73MB PDF 举报

动态分析Android恶意软件随着预计到2017年全球将有10亿台Android设备投入市场，网络犯罪分子自然也将他们的恶意活动扩展到了谷歌的移动操作系统。从2012年到2013年，威胁研究人员报告了Android恶意软件的显著增长，每天大约有700个新应用发布，这使得对这些新出现的可疑应用进行快速检测和隔离的需求变得紧迫。本研究论文由VU University Amsterdam的计算机科学系，互联网与Web技术专业硕士生Victor van der Veen完成，导师包括教授Herbert Bos博士和Christian Rossow博士。其研究重点是TraceDroid分析平台，这是一个针对Android应用的可扩展、自动化动态分析框架。该平台的目标是通过一种名为TraceDroid的全面追踪方案，有效地识别出可疑甚至可能是恶意的应用程序。 TraceDroid分析平台的设计旨在提供一种高效的解决方案，能够在海量的新应用中快速筛选出可能的安全威胁。它采用动态分析方法，通过监控应用在实际运行环境中的行为，捕捉关键操作和数据流动，以便及时发现潜在的恶意行为模式。这个平台不仅能够检测恶意代码，还提供了进一步的后处理手段，如日志记录和行为分析，帮助安全研究人员深入理解可疑应用的行为特征，从而准确地将其标记为恶意还是良性。通过TraceDroid，研究人员能够更加系统地评估应用程序的安全性，减少了人工分析的负担，并提高了恶意软件识别的准确性和效率。这对于保护用户隐私和维护Android生态系统安全至关重要。然而，随着Android市场的不断扩张和技术的持续更新，动态分析工具也需要不断进化，以适应新的威胁和挑战。这篇论文不仅阐述了一种创新的恶意软件检测技术，还强调了动态分析在应对Android恶意软件问题上的关键作用，对于提高Android应用安全防护水平具有重要的理论和实践意义。未来的研究可能会围绕如何优化分析算法，提高分析效率，以及如何与静态分析相结合，构建更为全面的安全防护体系。

and by sharing the memory pages that contain the preloaded system classes,

Android also reduces the memory footprint for running applications.

Furthermore, as opposed to regular stack-based virtual machines — a mech-

anism that can be ported to any platform — the DVM is register-based and is

designed to speciﬁcally run on ARM processors. This allowed the VM develop-

ers to add more speed optimizations.

2.2.2 Bytecode

The bytecode interpreted by the DVM is so-called DEX bytecode (Dalvik EX-

ecutable code). DEX code is obtained by converting Java bytecode using the

dx tool. The main diﬀerence between the DEX ﬁle format and Java bytecode

is that all code is repacked into one output ﬁle (classes.dex), while removing

duplicate function signatures, string values and code blocks. Naturally, this

results in the use of more pointers within DEX bytecode than in Java .class

ﬁles. In general, however, .dex ﬁles are about 5% smaller than their counter-

part, compressed .jar ﬁles.

It is worth mentioning that during the installation of an Android application,

the included classes.dex ﬁle is veriﬁed and optimized by the OS. Veriﬁcation

is done to reduce runtime bugs and to make sure that the program cannot

misbehave. Optimization involves static linking, inlining of special (native)

methods (e.g. calls to equals()), and pruning empty methods.

2.3 Apps

Android applications are distributed as Android Package (APK) ﬁles. APK

ﬁles are signed ZIP ﬁles that contain the app’s bytecode along with all its

data, resources, third-party libraries and a manifest ﬁle that describes the app’s

capabilities. Figure 2.3 shows the simpliﬁed process of how Java source code

projects are translated to APK ﬁles.

Figure 2.3: Android application build process

To improve security, apps run in a sandboxed environment. During installa-

tion, applications receive a unique Linux user ID from the Android OS. Permis-

sions for ﬁles in an application are then set so that only the application itself has

access to them. Additionally, when started, each application is granted its own

VM which means that code is isolated from other applications. It is stated by

the Android documentation that this way, Android implements the principle of

least privilege as each application has access to only the components it requires

to do its work

2.3.1 Application components

We now outline a number of core application components that are used to build

Android apps. For more information on Android application fundamentals, we

refer to the oﬃcial documentation

Activities

An activity represents a single screen with a particular user interface. Apps are

likely to have a number of activities, each with a diﬀerent purpose. A music

player, for instance, might have one activity that shows a list of available albums

and another activity to show the song that is currently be played with buttons

to pause, enable shuﬄe, or fast forward. Each activity is independent of the

others and, if allowed by the app, can be started by other applications. An

e-mail client, for example, might have the possibility to start the music app’s

play activity to start playback of a received audio ﬁle.

Services

Services are components that run in the background to perform long-running

operations and do not provide a user interface. The music application, for

example, will have a music service that is responsible for playing music in the

background while the user is in a diﬀerent application. Services can be started

by other components of the app such as an activity or a broadcast receiver.

Content providers

Content providers are used to share data between multiple applications. They

manage a shared set of application data. Contact information, for example,

is stored in a content provider so that other applications can query it when

necessary. A music player may use a content provider to store information

about the current song being played, which could then be used by a social

media app to update a user’s ‘current listening’ status.

Broadcast receivers

A broadcast receiver listens for speciﬁc system-wide broadcast announcements

and has the possibility to react upon these. Most broadcasts are initiated from

the system and announce that, for example, the system completed the boot

procedure, the battery is low, or an incoming SMS text message was received.

Broadcast receivers do not have a user interface and are generally used to act as

a gateway to other components. They might, for example, initiate a background

service to perform some work based on a speciﬁc event.

Two types of broadcasts are distinguished: non-ordered and ordered. Non-

ordered broadcast are sent to all interested receivers at the same time. This

means that a receiver cannot interfere with other receivers. An example of such

http://developer.android.com

http://developer.android.com/guide/components/fundamentals.html

broadcast is the battery low announcement. Ordered broadcasts, on the other

hand, are ﬁrst passed to the receiver with the highest priority, before being

forwarded to the receiver with the second highest priority, etc. An example for

this is the incoming SMS text message announcement.

Broadcast receivers that receive ordered broadcasts can, when done process-

ing the announcement, decide to abort the broadcast so that it is not forwarded

to other receivers. In the example of incoming text messages, this allows vendors

to develop an alternative text message manager that can disable the existing

messaging application by simply using a higher priority receiver and aborting

the broadcast once it ﬁnished handling the incoming message.

Intents

Activities, services and broadcast receivers are activated by an asynchronous

message called an intent. For activities and services, intents deﬁne an action

that should be performed (e.g., view or send). They may include additional

data that speciﬁes what to act on. A music player application, for example, may

send a view intent to a browser component to open a webpage with information

on the currently selected artist.

For broadcast receivers, the intent simply deﬁnes the current announcement

that is being broadcast. For an incoming SMS text message, the additional data

ﬁeld will contain the content of the message and the sender’s phone number.

2.3.2 Manifest

Each Android application comes with an AndroidManifest.xml ﬁle that in-

forms the system about the app’s components. Activities and services that are

not declared in the manifest can never run. Broadcast receivers, however, can

be either declared in the manifest or may be registered dynamically via the

registerReceiver() method. The manifest also speciﬁes application require-

ments such as special hardware requirements (e.g., having a camera or GPS

sensor), or the minimal API version necessary to run this app.

In order to access protected components (e.g., camera access, or access to the

user’s contact list), an application needs to be granted permission. All necessary

permissions must be deﬁned in the app’s AndroidManifest.xml. This way,

during installation, the Android OS can prompt the user with an overview of

used permissions after which a user explicitly has to grant the app access to use

these components.

Within the OS, protected components are element of a unique Linux group

ID. By granting an app permissions, it’s VM becomes a member of the accom-

panying groups and can thus access the restricted components.

2.3.3 Native code

It may be helpful for certain types of applications to use native code languages

like C and C++ so that they can reuse existing code libraries written in these

languages. Typical good candidates for native code usage are self-contained,

CPU intensive operations such as signal processing, game engines, and so on.

Unlike Java bytecode, native code runs directly on the processor and is thus not

interpreted by the Dalvik VM.

2.3.4 Distribution

Android users are free to install any (third-party) application via the Google

Play Store (previously known as the Android Market). Google Play is an online

application distribution platform where users can download and install free or

paid applications from various developers (including Google self). To protect

the Play Store from malicious applications, Google uses an in-house developed

automated anti-virus system named Google Bouncer (discussed in more detail

in Chapter 6).

Users have the possibility to install applications from other sources than

Google Play. For this, a user must enable the unknown sources option in the

device’s settings overview and explicitly accepts the risks of doing so. By using

external installation sources, users can install APK ﬁles downloaded from the

web directly, or choose to use third-party markets. These third-party markets

sometimes oﬀer a specialized type of applications, such as MiKandi’s Adult app

store

, or target users from speciﬁc countries, like Chinese app stores Anzhi

and Xiaomi

(a popular Chinese phone manufacturer).

2.4 Malware

Recent reports focusing on mobile malware trends estimate that the number of

malicious Android apps is now in the range of 120,000 to 718,000 [1, 30, 38, 65].

In this section, we take a closer look at mobile malware characteristics, how they

are distributed and what data sets are publicly available for malware researchers.

2.4.1 Types of malware

The majority of Android malware can be categorized in two types, both using

social engineering to trick users into installing the malicious software.

Fake install/SMS trojan The majority of Android malware is classiﬁed as

fake installers or SMS trojans. These apps pretend to be an installer for le-

gitimate software and trick users into installing them on their devices. When

executed, the app may display a service agreement and, once the user has agreed,

sends premium rated text messages. The promised functionality is almost never

available. Variants include repackaged applications that provide the same func-

tionality as the original — often paid — app, but have additional code to secretly

send SMS messages in the background .

SMS trojans are relatively easy to implement: only a single main activity

with a button that initiates the sending of an SMS message when clicked is

required. It is estimated that on average, each deployed sample generates an

immediate proﬁt of around $10 USD [38]. This type of attack is also referred to

as toll fraud. High proﬁt and easy manufacturing make toll fraud apps popular

among malware authors.

http://www.mikandi.com

http://www.anzhi.com

http://app.xiaomi.com

Spyware/Botnet Another observed type of Android malware is classiﬁed as

spyware and has capabilities to forward private data to a remote server. In a

more complex form, the malware could also receive commands from the server

to start speciﬁc activities in which case it is part of a botnet. Spyware is likely

to use some of the components described in Section 2.3.1. Broadcast receivers

are of particular interest as they can be used to secretly intercept and forward

incoming SMS messages to a remote server or to wait for BOOT COMPLETED to

start a background service as soon as the device is started.

In the summer of 2012, the sophisticated Eurograbber attack showed that

these type of malware may be very lucrative by stealing an estimated €36,000,000

from bank customers in Italy, Germany, Spain and the Netherlands [39].

2.4.2 Malware distribution

A problem with third-party marketplaces described in Section 2.3.4, is the lack

of accountability. There are often no entry limitations for mobile app developers

which results in poor and unreliable applications being pushed to these stores

and making it to Android devices. Juniper Networks ﬁnds that malicious appli-

cations often originate from these marketplaces, with China (173 stores hosting

some malware) and Russia (132 ‘infected’ stores) being the world’s leading sup-

pliers [38].

One of the issues Android has to deal with in respect to malware distribution

is the loose management of the devices. Over the past few years, Android

versions have become fragmented, with only 6.5% of all devices running the

latest Android version 4.2 (codename Jelly Bean). More than two years after

its ﬁrst release in February 2011, a majority of Android devices (33.0%) is still

running Android 2.3.3–2.3.7 (codename Gingerbread)

. This fragmentation

makes new security features only available to a small group of users who happen

to use the latest Android release. Any technique invented to prevent malicious

behavior will never reach the majority of Android users, until they buy a new

device.

One of the security enhancements in Android 4.2, for example, is the more

control of premium SMS feature

. This feature notiﬁes the user when an

application tries to send an SMS message that might cause additional charges.

This feature would prevent a large portion of the previously discussed SMS

trojans, but is unfortunately not attainable for the majority of Android users.

New Android releases also come with bugﬁxes for core components to pre-

vent against arbitrary code execution exploits. Android versions prior to 2.3.7

are especially vulnerable to these root exploits (examples include rage against

the cage

, exploid

and zergRush

). While these exploits were originally de-

veloped to overcome limitations that carriers and hardware manufactures put on

some devices, they have also been used by malware to obtain a higher privilege

level without a user’s consent. This approach allows malware to request only a

few permissions during app installation, but still access the entire system once

the app is started.

http://developer.android.com/about/dashboards/index.html

http://source.android.com/devices/tech/security/enhancements.html

http://dtors.org/2010/08/25/reversing-latest-exploid-release

http://thesnkchrmr.wordpress.com/2011/03/27/udev-exploit-exploid

http://github.com/revolutionary/zergRush

剩余108页未读，继续阅读

gxnncbx

粉丝: 0
资源: 2

TraceDroid动态分析：应对2013年激增的安卓恶意软件

Android恶意软件检测：AndroDialysis分析Intent效能

移动终端安全：2018年Android恶意软件增长趋势

AndroCompare: 快速检测Android应用差异与重打包

ANDROID MALWARE

Android-Malware-Analysis_2013:2013 年进行了 Android 恶意软件分析。分析了 30 个 Android 恶意软件。 #Dynamic 分析 #CodeReview #LogCat #NetworkTraffic #IP-lookup #Data Compromised

Hacking.Android.1785883143

引擎：Droidefense：先进的Android恶意软件分析框架

基于相似度检测与隐私分析的Android恶意软件研究

利用序列模式挖掘检测恶意软件的新方法

基于Flask，mysql slope one的图书推荐系统全部资料+详细文档.zip

最新资源