With ever growing desire to access and control everything on a single click, smartphones manufacturers are adding number of features in devices. Similarly users are spending a good amount of their personal time using smartphone. Now a days many professional and personal activities are carried out using smartphones like internet banking, personal/professional networking, information gathering and sharing, spending leisure time etc. During all these activities most of the time safety of information available on user device is compromised either knowingly or unknowingly. Sadly manufacturers, developers, owners, users of device are not taking smartphone information security seriously. While buying a PC (Desktop/Laptop), owner demands – manufacture provides antivirus-antimalware software either free or at negligible price. But while buying/selling smartphone, this is conveniently ignored. Today smartphones store much more sensitive data than PCs, are used by greater number of people from very early age of life than any other digital device. This shows need to provide security to smartphone at high level. Approach discussed in this paper is static analysis of SMS and Androidpermissions and is designed for network service providers. In dynamic analysis, prevention method for user device is provided. This will help user in identifying botnet attacks from SMS as C & C while analysing dangerous permissions of Android applications to identify probable misuse of Android applications.
management is very limited: either you authorize every- thing or you cancel the installation. Additional permission management systems (such as Privacy Guard Manager, Permission Master, XPrivacy, or DonkeyGuard) can be installed to enhance the basic native Android system by allowing users to modify permissions after the installation of applications. All these permission management appli- cations follow an Identity-Based Access Control model, i.e., the user has to control every permission for every installed application. Although IBAC allows fine-grained access control, it is not suitable for managing hundreds of permissions. Scalability issue has been studied by the access control models research community that proposed the use of abstractions leading to high-level authorization rules making global access control policies more under- standable. Nonetheless, applying these models requires to understand the associated abstractions and thus suf- fer accessibility for non-technical users. More recently, Google has enhanced the native Androidpermissions management system in version 6.x by (1) allowing users to modify permissions at run time and (2) reducing the number of permissions. However, it is no more possible to have a fine-grained control on applications (more details are given in Section 2.2).
One method used to increase user control over their device, while still retaining full compatibility with all applications is the technique of allowing users to set constraints upon the application’s use of permissions at install time. This was demonstrated by Nauman, Khan and Zhang in  with their Apex framework’s Poly installer, which contributed a modified Android installer environment, allowing for the selection of permissions. This approach of install-time granularity is con- venient (as users are already familiar with being prompted for permissions at install time), although it does naturally require its modifications to be made to the Android operating system, which may hinder wider adoption. Likewise, the SAINT  proposal introduced a modified install-time interface and pro- cedure for the granting and denying of permissions, as part of the installer.
Abstract— the android security model is based on an authorization and sandbox manner. Each application runs in its own Dalvik Virtual Machine with a unique ID assigned to application. This prevents an application from using information/data of another application. Although Android is most widely used, there exists a lack of applications in order to completely benefit from this operating system. Thus, third party application developers create new applications and launch them in the Android Market. This permits users access to thousands of applications; it is however important that the user needs to totally trust the applications before installing them. It is for this reason that every application publishes the permissions that it requires during installation. The user can either grant all permissions or deny all, in which case, the installation of the application is aborted. In order to distribute these applications Google came up with Android Market. Here users can access both paid and free applications. Every Android phone has this application and hence users can browse and download any application they entail from Android Market. However, there have been many malicious applications published in Android Market. Hence it means a necessity for Google to test each and every application and fresh the Android Market by eradicating malwares. It is also important to see to it that the loopholes and bugs of current applications are not exploited by hackers. One way in which an attacker can entice users to download the malevolent software is by repackaging applications using reverse engineering tools. The attacker changes the code in order to incorporate the spiteful code and repackages the application and publishes them in the app market. Users typically cannot differentiate between the malware application and the legitimate application and thereby end up installing the malware. Reverse Engineering is a process with the aid of which we can discover and understand the complete working of an application by learning its function, structure and functions. In this project the tools we use for reverse engineering are AdvanceApkTool, Dex-Manger, DextoJar and Jd-Gui
Detecting whether an app has legitimately accessed a given re- source is straightforward: we compare its runtime behaviour with the permissions it had requested. Both users and re- searchers assess apps’ privacy risks by examining their re- quested permissions. This presents an incomplete picture, however, because it only indicates what data an app might ac- cess, and says nothing about with whom it may share it and under what circumstances. The only way of answering these questions is by inspecting the apps’ network traffic. However, identifying personal information inside network transmissions requires significant effort because apps and embedded third- party SDKs often use different encodings and obfuscation techniques to transmit data. Thus, it is a significant technical challenge to be able to de-obfuscate all network traffic and search it for personal information. This subsection discusses how we tackle these challenges in detail.
Permissions are a vital security mechanism which guards against the misuse of hardware and software resources ; however, it relies on the user’s decision to accept the permissions of an app and other built-in features mainly the intents deprecate such security protections. Most malware need to use some permission to achieve their malicious goals which they must declare in the Manifest file and ask the users for approving the permissions before installation of app. Similarly, malware apps use intents to carry out malicious actions which they must declare in the Manifest file but do not ask the users for approval. This design flaw on Android is exploited by malware apps to carry out stealthy malicious actions. Intents have extended a number of known and unknown legitimate covert channels to malware app. Although, a significant research is done on permissions and API calls for detection of malware, however, intents remained almost untouched before starting this research work. There was no published works where intent was used as a key feature for detection of malware at the start of PhD research in 2013.
This paper applies the empirical software engineering analysis on the permissions in Android apps with several variables such as, Price, Number of Downloads and Rating. The findings indicate that all the variables have correlation with Androidpermissions, which means they have influence to some degree on the permissions. We also highlighted the top ten most used permissions in mobile apps, some permission are necessary but most of the permissions invade user’s privacy, especially if they involve modifying user’s data and reading sensitive data.
. Felt A P, Chin E, Hanna S, et al. Androidpermissions demystified[C]//ACM Conference on Computer and Communications Security. ACM, 2011:627-638.  Yuxiang Li, BoGang Lin. Design of Application Security Policy Consolidation System Based on Android Repackaging [J]. Netinfo Security. 2014(1):43-47.
In this work, the use of static malware detection in android malware apps was thoroughly reviewed. A comparison of current job has been provided with regard to certain criteria. The review identified knowledge gaps in the current job, highlighting significant problems and opening problems that will guide future study initiatives. Analysis of static Android malware dominates the current job. Future work may consider reviewing other methods such as dynamic studies or the use of methods of hybrid assessment or deployment of metadata. Except in a few cases, sharing research datasets and tools among researchers lingered unaddressed. Hardening deep learning models against various assaults on adversaries and detecting, describing and measuring concept drift are essential in future job on malware detection for Android. In addition, scientists need to bear in mind the restriction of deep learning techniques such as absence of transparency and its non- autonomous model for building more effective models.
Wang et al.  accomplished assorted Network Traffic analysis with detection at TCP and HTTP levels. They considered TCP flow rooted attributes and HTTP Request attributes. The authors implemented the work using the Decision Tree algorithm and outlined the detection rate of 99% with HTTP based attributes. The detection rate with TCP based attributes was 98%. The researchers in  extricated features from HTTP header fields of malicious traffic in Android devices and further implemented clustering on those features. Their work showed the detection precision of around 90 percent. The authors illustrated the families of malware on the basis of the HTTP traffic data. Shabtai et al.  detected that few malicious applications had the potential to self-update and the authors used TCP traffic analysis to detect such samples. They also utilized machine learning techniques for the generation of traffic patterns and then discovered malicious applications. The
I have used malware samples from Virusshare website. I actually have downloaded 24,317 samples, that was uploaded on 2014- march-24. From this a number of the APK are used for the coaching dataset and remaining for detection section. conjointly a number of the applications are downloaded from varied sites. And reckoning on the behavior of the application it's divided into subcategory. a number of them known as as malware if the first perform is to transfer the separate payload. If malware application stole data from android device then the android application is assessed as stealing of credentials. conjointly some application classified as sent the SMS message.
The Android-based IoT platform named "Android-Things" was first unveiled by Google. It is the first platform dedicated to IoT devices. "Android-Things" is an upgraded version of the existing Google's Internet platform, Brillo. Unlike the C/C++ language used in Brilo, it enables Android developers to easily develop IoT products [2, 3] by using existing Android development tools such as Android Studio, JAVA language, Android SDK in the same way. In addition, the hardware of "Android-Things" includes Intel Edison, Pico NXP, Raspberry Pi 3, etc. Each hardware is equipped with SOC (System On Chip), RAM, and wireless communication devices. "Android-Things" basically supports various sample code examples such as Doorbell and Bluetooth Audio, making it easier for developers to access.
Android uses a specific logging facility and it is quite unknown. Unfortunately enable by default. Android has 3 or 4 different logs depends on the phone model. These logs are not plain text files like in Unix or Linux. These logs are in fact circular memory buffers. It means they have very unique size. These logs are handles by Character device. Files like character device drivers in linux and these drivers are not easy to handle. There is a built in tool in every single android phone. Which will help us to manage or to read these logs. Log is a logging class that you can utilize in your code to print out messages to the LogCat. Common logging methods include
DOI: 10.4236/jis.2019.102004 77 Journal of Information Security three research studies. Pelet  explains that Android system permission model has three major categories; one of them is the dangers categorization. The cur- rent study aligns with Pelet study by finding a solution for this dangers categori- zation. Ayed  concluded that there is a need to come up with a solution to help users know when applications use their personal information, the current study also tackles this issue. Felt  noted that the permission requested by an application do not indicate whether the permission guidelines have other unno- ticeable accesses to other more sensitive information or not. Felt recommended finding automated solution to cover this gap which supports this study regard- ing the dangers associated with mobile application permissions.
The example shown in Figures 9 utilises set intersection while that in Figure 10 shows set subtraction as well. In figure 10 the “deny” privilege given to set B is specific to the permission in question. This means that members of set B do not get “WRITE” access to the records by this set of Partial Permissions. It is still possible that they may gain access to the records through some other permission. This specific denial is enabled due to the fact that the PID (x) of both Partial Permissions is identical. If a more general denial were required then the “deny” privilege could be specified separately. This example illustrates the fine level of control that can be achieved through the use of Partial Permissions.
enumerated in the manifest and require user consent at "time of use" to enable, whether via a prompt or an in-content user mediated UI. . . . When the user is prompted for explicit permissions, they need to be informed what is requested, why it's requested, and how the app will use data
compile applications and use static data flow analysis to determine when sensitive data, such as device identifiers, flow to the network. PiOS [ Ege11 ] and AndroidLeaks [ Gib12 ] are the initial static analysis duals of TaintDroid for iOS and Android, respectively. Flow- Droid [ Arz14b ] uses context, flow, field, object, and life-cycle sensitive static taint analysis to detect privacy leaks in applications. DroidSafe [ Gor15 ] models the Android runtime to increase precision of static information flow analysis on Android. IccTA [ Li15 ] resolves inter-component communication to extend FlowDroid to detect cross-component privacy leaks. Amandroid [ FWR14 ] provides a general static analysis framework that can detect data leaks, data injection vulnerabilities, and API misuse. AppIntent [ Yan13 ] uses static analysis to build test cases of events and interactions required to trigger a sensitive data leak and then runs the test case to execute the application and observe the sensitive data leak. MudFlow [ Avd15 ] uses static taint analysis to extract an application’s sensitive data flow be- haviors to differentiate between normal flows in benign applications and abnormal flows in malicious applications. FlowCog [ Pan18 ] uses NLP to analyze the text within graphical user interfaces to infer whether the sensitive data leaks detected with static taint tracking are justified by the user interface. Feng et al. [ Fen15 ] identify applications that aggregate privacy- sensitive user data by tracking accesses of such data and estimating the flow of the data by building dynamic link-ability graphs. Oltrogge et al. [ Olt18 ] use a combination of static and dynamic analysis to analyze applications created by online application generators and find four application generators were stealthily collecting privacy-sensitive user data. Bhoraskar et al. [ Bho14 ] identify several cases of advertisements requesting privacy-sensitive user data from children by static analysis to identify execution paths and binary rewriting for targeted execution. Zhang et al. [ Zha15 ] create behavior graphs describing triggering conditions and information flows to generate application descriptions that disclose such behaviors. AutoPPG [ Yu15 ] characterizes an application’s data flows using static analysis and generates sentences for privacy policies to describe the behaviors. Reaves et al. manually analyze data flows involving financial and account information in branch-less banking applications to identify vulnerabilities in processing financial transactions or authenticating the user. Bashir et al. [ Bas16 ] propose using re-targeted ads for tracking information flows between different ad exchanges.
The dangerous permissions are those permissions that are frequently used by malware apps and have more risk to access and exploit different sensitive resources and private data. Examples of frequently used permissions by benign apps are: Full Network access, Create/Add/remove/user accounts, Delete/Modify USB contents and Read/write/modify contacts. Malware apps usually use permissions: Read phone status/ID, Access Network state, Send SMS/MMS, Receive boot complete, Receive SMS, Delete/Modify USB contents, and your location. There are a few malware-friendly permissions, which are seldom used by the benign ones, e.g., Access Network state, Re- ceive boot complete, Restart packages, Mount/Unmount File system, Set wallpapers, Read/write history bookmarks of browser and Write APN set- tings.