Peterism

German researcher Karsten Nohl has cracked the encryption used for GSM.  His team has made information and tools needed to replicate the attack with a somewhat modest set up.    The A5/1’s 64-bit encryption key used in GSM is simply too short for the kind of computing power widely available today.  Considering that the technology is over 20 years old, however, it’s robustness is still remarkable.

Here’s the A5/1 Cracking Project’s website.

An interesting report by CNET News.  How do you define evil?  I suppose one way to not do evil is to write the code so that it consumes less resources, either in terms of CPU cycles or memory (or both if you can!), thus reducing the power dissipated in millions or billions of CMOS Flip-Flops.  Just think about the implications of wasted charges/discharges and unnecessarily-spent batteries.  Wait, maybe I’m getting off topic…

So I’ve been wanting to get my hands dirty at cooking up an Android app, and have had dreamed up a few ideas. Some of these ideas have since been implemented by others (barcode scanner with camera that searches for products and prices online, music “recognizer” like Shazam, etc). The latest idea that I have is a mobile app that records live phone conversation on demand.

Quick searches for existing solutions suggest that there are no apps of this kind for the Andoird and the iPhone, but a few good candidates may be available for the Symbian as well as for Windows Mobile.  I’m not certain about the WebOS that newer Palm devices run on.
The idea seems simple enough, but the actual implementation seems to have been curbed by limitations of the baseband processor in most smartphones.  From what I have gathered, most smartphones incorporates two major processors.  One of them is the “general purpose” processor, or that application processor that runs the OS and applications.  The other is a “special purpose” DSP  or sometimes referred to as the baseband processor that handles real-time voice encoding and decoding.   While it’s fairly straight-forward to record and encode local voice using the application processor, capturing the output of the baseband processor, or the remote voice, seems to have caused issues with most developers.

In my quest to write a conversation recorder app for the Android, I came across this class:
[java]MediaRecorder.AudioSource[/java]
One of the values available is:
[java]public static final int VOICE_CALL[/java]
Voice call uplink + downlink audio source
Constant Value: 4 (0×00000004)

This is available since API Level 4, which corresponds to Android 1.6.  It then appears deceptively simple to just set
[java]MediaRecorder.AudioSource = VOICE_CALL;[/java]
to record both the uplink (local) and downlink (remote) audio feeds.  I don’t actually have an Android phone to test on, but if you do, and have the means to load your code onto your Android phone, please let me know if you get 2-way voice recording going.  As I’ve said, it may depend on the capabilities of the baseband processor you have.

I’m eyeing on the HTC Passion/Google Nexus One, which is rumored to be based on Qualcomm’s Snapdragon QSD8×50.  The QSD8650 is especially interesting, with some reports having said that it may be clocked at 1.3GHz, with the capabilities to run on both the CDMA and GSM families of 3G data networks, making it a powerful world phone.  Detailed specs are especially hard to find, but I’m hoping the baseband processor inQSD8×50 will expose the downlink audio to the application processor, by perhaps providing some sort of DMA to the cache that the baseband processor uses.

I’ll report my findings as more details are available in the coming days, I hope, as the Passion/Nexus One is supposed to be coming out in as early as January 2010!

This course will introduce basic concepts needed to understand, design, and implement wireless distributed embedded systems. Topics include: a) design implications of energy, and otherwise resource-constrained nodes; b) network self-configuration and adaptation; c) data routing and transport; c) applications; and e) software design issues. The course will be heavily project based. Working knowledge of C programming in the UNIX environment (particularly GNU/Linux) is assumed.

The Department of Defense CIO office has released a new guideline which is aimed at easing open source software adoption.

Department of Defense CIO David Wennergren’s revised guidance (PDF)