Prof. Dr. Eric Bodden

Since Google Code is shutting down, TamiFlex has found a new home on Github. We have tried our best to move the entire webpage and infrastructure there. Please let us know in case you find anything missing.

Cross-posted from SEEBlog

On 17th of march, we organized our first Android Hacking event. Our participants (a mix of students, security researchers, PhD-students and Post-Docs) had to solve various Android-based challenges on different levels of complexity. Each challenge involved reverse-engineering a specific application without access to the app’s source code – similar to what malware analysts need to accomplish in their daily jobs. Inside these apps, passwords needed to be found, key checking algorithms needed to be understood, and hidden functionality had to be discovered. To accomplish this task, the participants were using different analysis techniques including debugging, decompilation, and fuzzing.

The event was not only great fun for  both the participants and the organizers, but also allowed us to provide free CodeInspect licenses for the day, to be used and tested on the challenges. We were very satisfied with the feedback we got on the tool – we’re making rapid progress towards a stable product. Stay tuned for commercial CodeInspect offerings. In the meantime, our free beta program is still running.

At almost midnight, the winners of the challenges were finally found: Andreas Wittmann, Max Weller and Daniel Magin scored best. Congratulations from the Android team @ SSE.

Cross-posted from SEEBlog

The Computers & Security journal, Elsevier, published online, recently, our paper “Incorporating Attacker Capabilities in Risk Estimation and Mitigation“. We propose in this paper the use of attacker capabilities in estimating the risk of threats. Attacker capabilities are the abilities to access system resources that allow to attack the system. We argue that the proposed factor allows the experts to have close risk estimates, which would increase the confidence in risk assessment.

Cross-posted from SEEBlog

We have extended the submission deadline for SOAP. You still have until March 31st to submit your paper! We are looking forward to your submission!

Cross-posted from SEEBlog

We have extended the submission deadline for SOAP. You still have until March 31st to submit your paper! We are looking forward to your submission!

Cross-posted from SEEBlog

In Java 8, Oracle added support for Lambda expressions to the Java programming language and the Java Virtual Machine (JVM). Though Android apps are also written in Java, this however doesn’t automatically make them available to app developers. In fact, it takes some time until Android catches up with newer Java developments.

The build chain for Android is (at least at the moment) built on top of the Java build chain: The normal Java compiler takes Java source files and creates Java class files. These files then serve as inputs to Android’s “dx” tool which finally emits the Dalvik bytecode that can be run on an Android device or emulator. In version 19 of the Android build tools, support for Java 1.7 class files was added – with the usual delay (Java 1.7 came out in July 2011, Android build tools v19 came out in April 2012). Up to now, that was the end of the line. But now, Java 1.8 support might be around the corner.

Those who have followed the development of the smali/baksmali tools closely mnight have noticed a recent commit with  a very interesting description:

Add lambda experimental dalvik opcodes

The story goes on in the same commit description:

 Add new -X/–experimental flag to [dis]assemble opcodes not in art yet

Add new opcodes liberate-variable, box-lambda, unbox-lambda, capture-variable, create-lambda, invoke-lambda

So the tool now supports opcodes that (judging by their names) will add Lambda support to Android. They are not yet available in ART, but given that the developer who goes by JesusFreke and is the person behind smali/baksmali is with Google’s Android team, chances are that we got an unintended sneak preview into the inner workings of the next Android release.

Let’s look around in the commit a bit further. There is a very interesting test case with the following line of code:

options.apiLevel = 23; // since we need at least level 23 for lambda opcodes

The most recent Android API level is currently 22 which is Android 5.1 Lollipop, released March 2015. So we are actually looking at stuff for something still in the works. Whether these opcodes will actually be part of Android 23 is not clear, though – they might as well be released later.

Speaking of opcodes, let’s have a look at the numbers. In the “old world”, 0xf3 – 0xf9 were ODEX opcodes. With ART becoming the new execution model, they have been deprecated together with much of ODEX (yeah, it’s still lurking in some corners, ok). Their place are now taking the Lambda opcodes, e.g., “invoke-lambda” at 0xf3. There’s a certain chance that these Opcodes will still be relocated before a final release and move away from the “internal” region.

In summary, there seems to be hope for all those who were missing Lambda expressions and Java 1.8 support on Android. Let’s see what happens next.

Cross-posted from SEEBlog

Our talk about our new Android bytecode analysis framework CodeInspect got accepted at the CARO (Computer Antivirus Research Organization) workshop 2015.

There will be also a demo-table reserved for CodeInspect where we will do some live reverse-engineering.

We are looking forward to an interesting workshop with a lot of interesting discussions.

Cross-posted from SEEBlog

Stephan Huber and I found a dangerous tapjacking attack in the Android Open Source Project (AOSP) which causes serious security issues. Tapjacking, which is similar to clickjacking for web applications, is an attack where the user clicks/taps on seemingly benign objects in applications, triggering unintended actions not actually intended by the victim[1]. This results to dangerous security issues. Unfortunately, we already found malware samples in the wild that include our attack. To the best of our knowledge, the attack seems to apply to all currently available Android versions back til version 2.3. The attack, together with a patch, has already been submitted to the Android Security team who confirmed our attack and add our patch to the next major release of the AOSP. More details on the attack will follow as soon as the AOSP is patched. The contribution is nominated for Google’s Patch Award.

[1] Marcus Niemietz and Jörg Schwenk, UI Redressing Attacks on Android Devices, BlackHat Asia 2014

Cross-posted from SEEBlog

Over the past few days, the news has been full of a report of “dormant” malware that infected millions of Android devices. (German article here on Heise.de.) The malware previously went unnoticed by laying dormant for several hours, sometimes multiple days, after installation, in some cases even requiring a reboot of the device to become active. Dynamic-analysis procedures usually only run for minutes and for efficiency reasons do not simulate situations like reboot Contrary to the current perception, though, this problem had long been identified, and in fact today with this article we are revealing Harvester, a new tool to address exactly this problem.

Harvester* uses a unique novel combination of static and dynamic analysis and code transformation to (1) identify and eliminate emulator and timeout checks from apps, and (2) that way allows for the extraction of interesting runtime values such as reflective method calls, target numbers of calls to the SMS APIs, account-data hard-wired in the malware, etc. In addition, Harvester is resilient against virtually all current cases of code obfuscation.

As we show in our Technical Report (see below), Harvester can retrieve most runtime values of interest in a short amount of time, and can be used to significantly improve the quality of existing static and dynamic analysis tools.

In the past, we have successfully used Harvester to help retrieve inside information about current threats such as the banking trojan BadAccents we reported on earlier.

How does it work?

The main idea of Harvester is to apply dynamic analysis not to the original malware app but to a version of app that has been carefully altered to allow for an easy extraction of values of interest. Consider the original app code shown to the left. This app has an emulator check, returning early if the deviceId is all zeros. Using a specialized backwards slicing, Harvester determines that the check cannot influence our value of interest, in this case the number used in the sendTextMessage call. Therefore the check is simply eliminated from the app, as is all other code not influencing the value of interest. Executing this app thus immediately triggers the malicious behavior – no improved emulation or waiting required. Conditionals that may influence the value at hand are replaced by controllable boolean variables as shown to the right. Using a limited number of fast executions of the modified code, Harvester can quickly cover all necessary branches and extract all three relevant phone numbers.

Our report is currently under submission at a major conference. We plan to make the implementation available after the paper has been accepted for publication.

Technical Report

Harvesting Runtime Data in Android Applications for Identifying Malware and Enhancing Code Analysis (Siegfried Rasthofer, Steven Arzt, Marc Miltenberger, Eric Bodden), Technical report TUD-CS-2015-0031, EC SPRIDE, 2015. [bib]

* Patent pending

Cross-posted from SEEBlog

If you are interested in CodeInspect and would like to support us testing it, feel free to contact us (Siegfried Rasthofer) and we will provide you all the necessary information.

There is only one little requirement: due to legal restrictions (test license agreement), CodeInspect is currently only available to corporate customers.

Cross-posted from SEEBlog