The major German news station heute.de is reporting on our tool Harvester and on time bombs in app in general. Read the German article here.
In the meantime we are doing our best to get both CodeInspect and Harvester ready for roll-out. Stay tuned for more.
Cross-posted from SEEBlog
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
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
