One of the things that is very different about developing for Android and other mobile operating systems is that they don't guarantee to save your app's state when they suspend it. Most operating systems swap programs in and out of memory and suspend them without the programmer needing to know anything about i,t but Android will stop your application in its tracks and its is up to you to make sure it continues.
This is often difficult and it is the biggest reason for Android apps crashing and simply not doing what the user expects.
Now we have an interesting idea - lets automatically repair the damage that data loss inflicts:
Android apps should be designed to cope with stop-start events, which are the events that require stopping and restoring the execution of an app while leaving its state unaltered. These events can be caused by run-time configuration changes, such as a screen rotation, and by context-switches, such as a switch from one app to another.
When a stop-start event occurs, Android saves the state of the app, handles the event, and finally restores the saved state. To let Android save and restore the state correctly, apps must provide the appropriate support. Unfortunately, Android developers often implement this support incorrectly, or do not implement it at all.
This bad practice makes apps to incorrectly react to stop-start events, thus generating what we defined data loss problems, that is Android apps that lose user data, behave unexpectedly, and crash due to program variables that lost their values. Data loss problems are difficult to detect because they might be observed only when apps are in specific states and with specific inputs.
Covering all the possible cases with testing may require a large number of test cases whose execution must be checked manually to discover whether the app under test has been correctly restored after each stop-start event. It is thus important to complement traditional in-house testing activities with mechanisms that can protect apps as soon as a data loss problem occurs in the field.
In this paper we present DataLossHealer, a technique for automatically identifying and healing data loss problems in the field as soon as they occur. DataLossHealer is a technique that checks at run-time whether states are recovered correctly, and heals the app when needed. DataLossHealer can learn from experience, incrementally reducing the overhead that is introduced avoiding to monitor interactions that have been managed correctly by the app in the past.
As if a single malware app wasn't enough, it now seems that apps can collude with each other to stage an attack. It's a clever idea because each app only requests a small and innocent looking set of permissions but when put together much more becomes possible:
With the digital breakthrough, smart phones have become very essential component. Mobile devices are very attractive attack surface for cyber thieves as they hold personal details (accounts, locations, contacts, photos) and have potential capabilities for eavesdropping (with cameras/microphone, wireless connections). Android, being the most popular, is the target of malicious hackers who are trying to use Android app as a tool to break into and control device.
Android malware authors use many anti-analysis techniques to hide from analysis tools. Academic researchers and commercial anti-malware companies are putting great effort to detect such malicious apps. They are making use of the combinations of static, dynamic and behavior based analysis techniques. Despite of all the security mechanisms provided by Android, apps can carry out malicious actions through collusion.
In collusion malicious functionality is divided across multiple apps. Each participating app accomplish its part and communicate information to another app through Inter Component Communication (ICC). ICC do not require any special permissions. Also, there is no compulsion to inform user about the communication.
Each participating app needs to request a minimal set of privileges, which may make it appear benign to current state-of-the-art techniques that analyze one app at a time. There are many surveys on app analysis techniques in Android; however they focus on single-app analysis. This survey augments this through focusing only on collusion among multiple-apps. In this paper, we present Android vulnerabilities that may be exploited for a possible collusion attack. We cover the existing threat analysis, scenarios, and a detailed comparison of tools for intra and inter-app analysis. To the best of our knowledge this is the first survey on app collusion and state-of-the-art detection tools in Android.
How do you detect malware? It might be enough to know how to detect a type of malware and its possible variations:
Android, the most popular mobile OS, has around 78% of the mobile market share. Due to its popularity, it attracts many malware attacks. In fact, people have discovered around one million new malware samples per quarter, and it was reported that over 98% of these new malware samples are in fact "derivatives" (or variants) from existing malware families.
In this paper, we first show that runtime behaviors of malware's core functionalities are in fact similar within a malware family. Hence, we propose a framework to combine "runtime behavior" with "static structures" to detect malware variants. We present the design and implementation of MONET, which has a client and a backend server module.
The client module is a lightweight, in-device app for behavior monitoring and signature generation, and we realize this using two novel interception techniques. The backend server is responsible for large scale malware detection. We collect 3723 malware samples and top 500 benign apps to carry out extensive experiments of detecting malware variants and defending against malware transformation. Our experiments show that MONET can achieve around 99% accuracy in detecting malware variants.
Furthermore, it can defend against 10 different obfuscation and transformation techniques, while only incurs around 7% performance overhead and about 3% battery overhead. More importantly, MONET will automatically alert users with intrusion details so to prevent further malicious behaviors.
Apache has announced the release of Tomcat 11, as well as marking the 25th anniversary of the first commit to the Apache Tomcat source code repository since becoming an ASF project.
IBM is launching a new set of AI software engineering agents designed to autonomously resolve GitHub issues. The agents are being made available in an open-source licensing model.
