nion's blog

I felt the need to do a short writeup of what I actually did in the last time since I became fairly quiet in some parts of the net.
During the time I was mostly busy with working on my diploma thesis (I will hopefully rework my homepage soon and also upload the thesis pdf then) titled SMS Vulnerability Analysis on Feature Phones. During this study I was working on a modified version of OpenBSC (thanks to the great people developing this at this point!) that allows me to do over-the-air fuzzing of the short message service on so-called feature phones. The study aimed to not only look at one specific phone model for testing but also do a large scale analysis of the big players in that market section.

This has been interesting to us as SMS is known to be problematic from the past, feature phones are widely deployed on the market (compared to only ~16% smartphones, even though uprising), and it is not possible (or let's say not feasible if you want to test a large number of devices without patching the firmware blobs) to modify the underlying operating system for testing. The application platforms are less integrated into the operating system, have less abilities to interact with other applications on the phone, and have far less advanced APIs compared to open APIs on smartphones. Smartphones often provide the ability to run native code. During the work I found bugs for all tested manufacturers (Nokia,Motorola,LG,Sony Ericsson,Samsung,Micromax (3rd biggest manufacturer in india)).

A large part of this work is the result of a talk with my colleague Collin Mulliner at the 27C3 congress and CanSecWest.
SMS-o-Death: from analyzing to attacking mobile phones on a large scale (slides)

Both conferences have been excellent (even though pretty different). Thanks to Dragos for organizing CSW, it was a blast! I also had the chance to visit TROOPERS. Although being a fairly young and small security conference (organized by ERNW), a pretty good one (in terms of people, overall atmosphere and also talks) and definitely worth a visit!

Being finished with my studies (well I don't have the official certificate yet) I will now look forward to work in a PhD position at the department I already work at, SecT. I will probably look into mobile handset security, system security and security of "modern" mobile communication systems (such as GSM,UMTS,...). I'm not really interested in the title at the end of the PhD, but working in this area and especially at university has been lots of fun to me (recently playing with femtocells) so far, so I try to keep it that way

That's it for the update on what has been going on.

P.S. I finally failed to resist and you can now as well follow me on twitter @iamnion

I was just looking into some specifications of the openmobilealliance when I got the content for todays WTF moment.
An MMS notification is usually sent over SMS and encodes various fields including the location of where the MMS content is located so the mobile phone can download it via e.g. WAP.

Now looking at WAP-209-MMSEncapsulation-20020105-a chapter 6.2. (Multimedia Message Notification) there's an interesting header field included in these notifications, X-Mms -Message-Size

Mandatory.
Full size of message in octets. The value of this header
field could be based on approximate calculation,
therefore it SHOULD NOT be used as a reason to reject
the MM.

Clearly the people who developed this must have taken some bad drugs. Adding a length field value to a header and allow it to be based on an approximation rather than an exact value just doesn't explain itself to me.