One step closer to modularizing security code

Eric | January 29, 2013

In my group we worry a lot about what the future of secure software engineering is going to look like, and we are trying to shape that future for the better by developing tools, methods and programming languages that support a secure software design and implementation. One thing we have noticed over the past years is that many current applications and frameworks suffer from the fact that their security-related code is scattered throughout the program, and tangled with other code that is not at all related to security. From all the talk about AOP, we know that scattering and tangling can have detrimental effects, but this is especially true when talking about security. The repeated news reports about zero-day vulnerabilities in the JDK, for example, are just one instance of that problem.

Aspects are meant to modularize crosscutting concerns. So why not just use AspectJ to modularize all security code? In principle yes, I guess that would be a step into the right direction. But it cannot solve the whole problem. One problem is the well-known fragile pointcut problem. As base logic changes, pointcuts need to be updated. One of the problems with the JDK, for instance, was that new code was added without putting appropriate security checks in place. That’s pretty much the same problem we are talking about. Someone still needs to say where checks need to go! Read the rest of this entry »

Comments Off on One step closer to modularizing security code

How useful are existing monitoring languages for securing Android apps?

Eric | January 28, 2013


… if you think that’s an interesting question then you might be interested in reading our latest publication. We have studied four existing languages for code instrumentation. The main selection criterion was that there was at least a somewhat stable implementation available. Also we ruled out tools such as TaintDroid which do not provide a language frontend.

Specifically, we investigated JavaMOP, Tracematches, DFlow Pointcuts and PQL. As we found out, all have their little problems, and no such language is ideally suited for the task.

Comments Off on How useful are existing monitoring languages for securing Android apps?

AOSD 2013 – Call for Participation

Eric | January 25, 2013

Dead all, I am happy to announce that the program for AOSD is now complete. Come and join us for an exciting conference in Japan!


12th International Conference on Aspect-Oriented Software Development
MODULARITY: aosd 2013
March 24-29, 2013
Fukuoka, Japan

The full program is online and registration is open.

Deadline for early registration: February 24, 2013

In cooperation with:

* Microsoft Research
* Graduate School and Faculty of Information Science and Electrical
Engineering, Kyushu University
* Oracle Corporation
* Fukuoka Convention and Visitors Bureau
* Kayamori Foundation of Information Science Advancement
* Rakuten, Inc.
* VMware, Inc.
* Cybozu, Inc.

Read the rest of this entry »

Comments Off on AOSD 2013 – Call for Participation

SC submission deadline is approaching

Eric | January 15, 2013

There’s still a chance to submit to SC 2013! 5 days left to submit an abstract, 10 days to submit a paper! We welcome your contributions!
For more information, see

Comments Off on SC submission deadline is approaching

Instrumenting Android Apps with Soot

Eric | January 8, 2013

I am excited to let you know that we have recently committed to the development Branch of Soot support for reading and writing Dalvik bytecode with Soot. (This code will also be contained in Soot’s upcoming release.) This supports consists of two major modules. One is called Dexpler, mainly developed by a group around Alexandre Bartel, and with some enhancements by Ben Bellamy and myself as well as Frank Hartmann and Michael Markert, two students of mine. Dexpler converts Dalvik bytecode into Jimple’s three-address code. This may sound simple – after all Dalvik code is register based and Jimple uses local variables which are quite similar to logical registers. However, things get tricky with respect to typing. Jimple is typed; every local variable is of some declared type. In Dalvik, registers are untyped, and during the execution of a method the same register can hold values of quite different types. Constants in Dalvik are also untyped: when loading a double or a long into a register, Dalvik just loads an eight-byte bit-pattern into the register without telling you whether it’s a long or double. But in Jimple we need this information. Thus getting the typing of Jimple locals right is quite tricky and took us a while. On the other hand, typed locals are great, as they allow for a simpler and more precise pointer analysis, among other things. Read the rest of this entry »

Soot Tutorial