Network Information

Whenever you join a company's, campus's, or employer's wireless network, does it ever feel like it is missing something? For instance, when you go to a cafe and join their wireless, there is a disconnect between the companies offerings (coffee) and the service you just received (wireless connectivity). Earlier in the semester I thought of a system that would bridge this disconnect. The system would provide information about the network which was recently joined. The information could be anything, but should be tailored to the company providing the wireless. An example of this could be the cafe providing information of products, sales, contact information, or privacy information regarding the internet.

To accomplish this, there would be some server running (could be the router providing internet/wireless) that would store the information to be provided. The information could be stored in anyway, but for me I chose to use XML as there are many parsers available. Here is an example of such an XML file describing the network, and some upcoming events.

   <name>University of New Orleans</name>  
      <title>Party at the library</title>  
      <description>Free food</description>  
      <title>Campus Meeting</title>  
      <description>Talk with the governor</description>  
      <eventLocation>Administration building</eventLocation>  

This XML file describes a campus network that may wish to provide students and other network users of upcoming events, but the idea is clear that other types of information may be presented as described above.

For one of my classes, I decided to craft this idea into an Android project. The fun part about this is that I would use service discovery to automatically discover the server on the network providing the information. This is in contrast to perhaps a static network address or some DHCP information similar to DNS information.

I chose to use zeroconf technology for the service discovery as there was an easy to use java version of mDNS (a portion of zeroconf) that I used for DAAP that works nicely in this situation (well not so nicely, but it works). The idea is that the network server that is providing the information, also registers a service of a network-info service type and clients that join the network request services of the network-info service type that was registered. The server responds and provides the information, which the client displays.

I created an Avahi XML file describing the service so that it would be automatically broadcast on boot. Avahi is an open source implementation of zeroconf and provides utilities such as this to advertise services.

<?xml version="1.0" standalone='no'?>  <!DOCTYPE service-group SYSTEM "avahi-service.dtd">  <service-group>    <name>UNO</name>    <service>     <type>_netfo._tcp</type>     <port>9090</port>    </service>  </service-group>  So now that the service is advertised and the information being provided is set up, we just need clients to connect.

Here are the screenshots of the implementation I wrote for my mobile computing class.

Screen presented after a server is discovered and information provided.
Screen presented when an even was clicked, providing more information.
 This is great. Imagine all the possibilities of having information from your network. If there are any great ideas that could take advantage of this, feel free to comment with them! One idea that I came up with after beginning the project is an emergency channel. Take the university campus example for instance. Imagine that campus police spotted an armed individual and wanted to alert everyone in as many ways as possible. They can send mass emergency texts, emails, etc. Using the clients connected and listening to network information could be alerted also. I wrote this quickly for the android application as well.

Clients receive a notification upon emergency information becoming available.

Information presented when the emergency is clicked.
Ok, so maybe budget cuts aren't as scary as armed individuals, but they are scary!

Python's any and all in C++

When working on some Project Euler problems with a friend, he used a handy little Python trick called all. Here is a typical use of all:

if all([x > 1 for key in some_list]):
   print 'True'  

Simply put, if every element of some_list is greater than 1, then true is returned. Similarly, there is another function called any which returns true is any element in a list is true. I decided to test out my C++ skills and write this. Here is my attempt.

template<class InputIterator, class UnaryFunction>
   bool all(InputIterator first, InputIterator last, UnaryFunction f) {
   bool allTrue;
   for(allTrue = true; first != last; ++first) {
      if(f(*first) == false) {
         allTrue = false;
   return allTrue;
template<class InputIterator, class UnaryFunction>
   bool any(InputIterator first, InputIterator last, UnaryFunction f) {
   bool anyTrue;
   for(anyTrue = false; first != last; ++first) {
      if(f(*first) == true) {
         anyTrue = true;
   return anyTrue;

Now to use these functions, simply use it like any other STL function. Make a function or functor that takes the type of the list, and pass it to the any or all function.

struct apply {
   bool operator() (int x) {
      if(x > 1) {
         return true;
      return false;

And now we just use it like you would expect.

int main() {  
   std::vector<int> integers;

   bool result = all(integers.begin(), integers.end(), apply());
   std::cout << "Result is: " << result << std::endl;
   result = any(integers.begin(), integers.end(), apply());
   std::cout << "Result is: " << result << std::endl;
   return 0;

Please give me your comments on what you think.

Tire Pressure Monitoring Systems

Recently there was a discussion in one of my classes where a student claimed that they read of an attack against the tire pressure monitoring system (TPMS) required in all United States automobiles. They claimed the attack could stop the car, accelerate the car, lock the breaks, or anything else conceivable. I was in disbelief so I did some research and made a presentation for our weekly Information Assurance Research meeting.

I found that the current attacks on TPMS are very limiting. The researchers were able to turn on and off the tire pressure and general information light, but only temporarily. Most experts agree that a more troubling matter exists with current TPMS implementations; they allow someone to track your car by listening to the wireless sensors in the tires themselves. I argue in my presentation, however, that tracking someone by this means would be more difficult than license plates, car color, car model, car year, car make, or toll tags.

The presentation also covers the researchers use of cheap hardware to decode the wireless signal. I found this aspect very interested. For those interested, here is the link: Tire Pressure Monitoring Systems (pdf)

Lesson from a Reference

I learned a valuable lesson recently. When implemented TOTP on the OTP Android application, I used the Java reference implementation from the draft RFC document. The outputs matched and I assumed everything was fine. Last week, I was given a heads up through email that  TOTP output values were not matching output values of other TOTP implementations. I assumed the other applications were wrong as I followed the true reference implementation.

I realized, however, that I was wrong. I was incorrectly using the source code by not verifying how the input was specified. The source attached to the document assumed that the ASCII seed had already been transformed into a hexadecimal string. For example, the seed in the reference implementation was "3132333435363738393031323334353637383930" which is the hexadecimal representation of the ASCII string "01234567890123456789". I thought that the long string was supposed to be entered by the user. If I would have though shortly about the ridiculous nature of that number, I may have realized my mistake.

I have released an update to the market correcting this error and a few other bugs. I fixed the activity stack to behave more in line with other Android applications (I didn't know much at the time of writing the older releases). I also cleaned up some interfaces to behave properly on different screen sizes.

Ultimate Search Widget for Android

All major browsers have done it. By providing different search providers, a web browser user is quickly able to search their favorite search engine by selecting the search provider and then the desired query. The Google Search widget or Android is great, except it only searches Google. Frequently I find myself typing search queries with the following pattern: "* Wikipedia," "* IMDB," etc. to quickly bring up the desired page. My brother and I decided it would be great if there was a widget of a similar fashion to the way modern web browsers handle searching. Ultime Search Widget is the result of this labor.

Ultimate Search widget is an Android widget that installs directly on your home screen and bears a similar appearance to Google's Search widget.

There is a subtle difference however, the Google favicon to the right. As per modern web browsers, by selecting the favicon, the searcher is able to select which search provider they would like to carry out their search.

After selecting the search provider, the searcher is able to enter a query. All the features of the Google Search widget are provided, such as voice searching and suggestions.

The current providers:
* Amazon
* Answers
* Bing
* Creative Commons
* Dictionary
* eBay
* Google
* Google Images
* Merriam-Webster
* Wikipedia
* Yahoo!
* Youtube

Wherever applicable, the search results will be the mobile version of the search provider to improve response times of search queries. The Ultimate Search Widget is available on the Android market for a 99¢.

Check it out!

Silverlight Resources

Recently T-Mobile USA put up a website T-Mobile Clue to tease the upcoming Samsung Vibrant cell phone. The website displayed a series of tiles covering an image. The tiles would slowly be removed and after four days, the image would be completely revealed. After realizing that the entire page was a Silverlight application, I decided to attempt to find the obscured image by examining the application using some of my reverse engineering skills picked up last semester.

I first examined the website's source code to find the actual Silverlight application which can be found here at the time of writing. Extracting this file would have been difficult if it weren't for Ubuntu assigning a zip icon for it. I simply double clicked the file and extracted the dlls.

I took the dlls and identified the one that was of importance (T-MobileClue.dll) and examined it in a PE Resource editor. I know realize that .NET Silverlight applications store resources differently than normal PE executables. Luckily there are applications similar to PE resource editors for .NET/Silverlight applications.

I used a program called Reflector to help go through the decompiled application. I quickly found by examining the source code that the obscured image to be revealed was the resource images/rebus.png. Reflector's resource browser quickly allowed me to open the resource. Sure enough this is the image that was revealed four days later. This was a few days ago so I do not feel bad revealing this information, but I will refrain from posting the rebus.png image here.

Proactive Secret Sharing

I have been researching proactive secret sharing for my master's thesis quite extensively. I was upset to see that no wikipedia article existed so I created one myself. Check it out!
Proactive Secret Sharing on Wikipedia

Google Code Project for DAAP Android Client

We have used Google Code Project Hosting to set up a project page for the Android DAAP client. This will hopefully keep DAAP from overriding this blog. This move also allows bugs, feature requests, and issues to be reported and well maintained. There is also a subversion repository provided by Google which will make handling commits between the two developers much easier. I hope to provide with the wiki section useful tutorials that explain some of the features, such as streaming, downloading of songs, queuing, etc. Releases will be posted there.

DAAP Android Client Updates

The first release of the DAAP client for Android had a bit more problems than I would like to admit. We have been happily working with many users to get the application to work in their situations, and in doing so, we have made the DAAP client far better than it was in its initial release. The changes below are great:

  • Major memory optimizations
  • Minor bandwith optimizations
  • Automatically detect local shares
  • Playlist support
  • Queue support
  • Rhythmbox as server support

By eliminated many buffers that were created very frequently, the DAAP client is now able to handle much larger libraries. It is also easy to navigate thanks to playlist support. Queue support is nice, but the interface is probably in its beta. The auto-detection of local shares is really hit or miss and I can find no reason for it. According to a couple of android bug reports I have found, Android does not support connecting to multicast sockets, but it has worked for me a few times, but not very consistently. This is strange. Streaming will come as soon as I can find a good way to do it in Android without skips and jutters.

My main point in this post is to get feedback from the users. Is the DAAP client working for you, and if not, which server are you using? Are there any suggestions? Also, if you like the application, please rate it positively.

DAAP Media Player released to Android Market

I am very happy to say that I have published the DAAP Media Player to the Android Market today and should be available for everyone to download! This is an initial release with many planned features to come, but I figured that everyone wanted something to use now. The application uses a heavily modified version of the Java Get It Together Client that has been stripped down to remove all GUI elements, all external libraries, and the integrated with an Android interface.  The media player portion may look familiar because it is a modified version of the default Music player interface from Android.

We only have one server to test it on, but the application is known to work with a mt-daapd/firefly media server.  Please comment on the functionality with other media servers. A google code project may be on the horizon. For more information on DAAP, please refer to wikipedia or my previous post.



TOTP on Android

Time-based One-time Password Algorithm is an expansion of the HOTP algorithm that uses time as the "moving counter" instead of a normal counter. Still is draft at the time of publishing, I decided that it would not be too difficult to add this to the mOTP application that is currently in the market.  A brief description of TOTP can be found on wikipedia and the full current specification here. Since I already went through the trouble of making mOTP have a multiple OTP framework, all I had to do was add a class and some error checks in the setup page.  I will upload the apks soon, but they are already available on the market.


HOTP on Android

I have updated the Android mOTP application to support the HOTP algorithm for One-Time Passwords.  This involved implementing HOTP in Java.  This was not such a chore thanks to Java's easy to use security tools.  However, after writing this from scratch, I realized at the end of the RFC was example source code in Java!  I used this reference implementation for the android app.  I did have to make a minor change to the reference implementation to support more than 10 digits of output for the generated password.

After this step was done, all that was required was to add an option to make a profile either a HOTP profile or a mOTP type, edit some database fields, and generate a new layout for the HOTP generation page.  The Mobile-OTP application is translated into three languages, English, Traditional Chinese, and Simplified Chinese.  A goal of mine was to have all additional strings required for this update to also be translated.  I have tried very hard to make this happen.

I also wanted to implement this change in such a way that if a third OTP comes around the corner (S/Key), that change wouldn't be so hard.  I didn't implement any design patterns per the Gang of Four, the code would not require that many modifications to support another algorithm.
Some screenshots for the visual people (often the first thing I look for when evaluating software):


    I have been reading about mDNS in preparation for the DAAP client that is coming along nicely.  mDNS is the component of DAAP applications that allows automatic discovery of shares on the local network. mDNS is a portion of Apple's Bonjour (formerly Rendezvous) protocol. The way that mDNS works is by essentially creating a pseudo-distributed DNS name server on the local network.  Whenever a client wants to discover information about which services reside on the local network, that client creates a query to a multicast address.  All machines that posses some DNS records will receive this query.  The machines that has information regarding that query will reply.

    JmDNS is an implementation of mDNS in Java that is very simple.  They have a sample application that fetches information about the network and displays what is discovered graphically.  I mimicked this code in an attempt to discover all DAAP servers on the network.  I always received information that a DAAP server existed on the network, but when my application attempted to resolve the name of the server, JmDNS would never issue the callback.  My application would wait indefinitely for this callback and never know how to talk to the server.  This was strange to me as wireshark showed that mDNS was behaving properly and returning the address when my application was resolving the name.  JmDNS was just not issuing the callback.  Even more strange was the sample application included in the source would always resolve.  I found a thread on the support forums at sourceforge where someone describes the same problem.  They noted that the only difference between their application and the sample one was that they request was issued in a thread.  Wrapping just the request for resolving a name in a thread strangely fixes the issue.  I filed a bug here.  Now we can move forward and incorporate the great feature of automatic server discover for DAAP into our android client.