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.
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
* IMDB
* 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!
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.
* Amazon
* Answers
* Bing
* Creative Commons
* Dictionary
* eBay
* IMDB
* 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.
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
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:
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.
- 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.
Subscribe to:
Posts (Atom)
