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.

I was trying to review my crim law reading last night in bed, and thought of the idea of using FSA to check legal citation.

If citation in legal writing conforms strictly to some predefined rules (either Bluebook or ALWD), then there’s no reason why the problem can’t be solved by a FSA which describes the finite number of rules set forth in those citation manuals. The solution seems pretty straight forward, and can be implemented fairly elegantly in either python or perl, off the top of my head. On the other hand, a functional language like list or scheme can probable implement achieve the same with significantly fewer lines of code.

More to come later…

Love the addition of jQuery Cookie.

http://www.onextrapixel.com/2009/10/13/how-to-display-form-fields-based-on-selection-with-or-without-jquery-cookie/

A Stumbleupon find.

I will be taking a look at the code when this semester is over…

http://www.xarg.org/project/php-facedetect/

For those programmers and mathematicians, here’s a brain exercise to walk through from the good folks at stackoverflow.com.

I stumpled upon this fairly interesting article and explanation about how a spelling corrector would be coded in Python.  This takes me back to Stat 110 at UCLA, and I thought it’s good for me to at least document this find for future reference.

Documents the details of a custom payment processor written to work with CiviCRM 2.x.