Crashing Android Messaging App

Recently, I decided to downgrade my phone from CyanogenMod 10.1 (Jelly Bean) to CyanogenMod 9.1 (ICS). I wanted to keep a few things, like Camera pictures and SMS. Android stores MMS and SMS messages in a SQLite database located in ./data/data/ I simply copied the mmssms.db file off my device before installing CM9.1. A problem arose when the Messaging app started crashing after replacing the mmssms.db in the freshly installed OS. Running logcat and opening Messaging app generated this error:

/DatabaseUtils( 2527): android.database.sqlite.SQLiteException: Can't upgrade read-only database from version 57 to 55: /data/data/
E/DatabaseUtils( 2527):     at android.database.sqlite.SQLiteOpenHelper.getReadableDatabase(
E/DatabaseUtils( 2527):     at
E/DatabaseUtils( 2527):     at android.content.ContentProvider$Transport.query(
E/DatabaseUtils( 2527):     at android.content.ContentProviderNative.onTransact(
E/DatabaseUtils( 2527):     at android.os.Binder.execTransact(
E/DatabaseUtils( 2527):     at Method)

After some investigation I found the answer on StackOverflow:

You can manually set the user_version of the SQLite database by entering PRAGMA user_version = 55; After I made this change, the Messaging app opened normally and there were no errors when watching logcat. Simple fix.

Some additional information about SQLite versions:

More »

Geolocate SSH Brute Force Attemps

Running a public facing server is an interesting endeavor. Whether you’re running a SSH, web, FTP or any other number of services, your system is constantly being bombarded by service scanning tools. Most of these tools have malicious intent and are testing hundred, if not thousands, of other public servers for weak SSH passwords or vulnerable web applications. Since running, I’ve always been interested in SSH scans I see in the server logs. Sometime hundreds of login attempts from users non-existent on the system.

Jan 12 19:46:15 regulus sshd[20524]: Invalid user brad from
Jan 12 19:46:17 regulus sshd[20526]: Invalid user remote from
Jan 12 19:46:19 regulus sshd[20528]: Invalid user internet from
Jan 12 19:46:21 regulus sshd[20530]: Invalid user postmaster from
Jan 12 19:46:23 regulus sshd[20532]: Invalid user squid from
Jan 12 19:46:25 regulus sshd[20534]: Invalid user ldap from
Jan 12 19:46:27 regulus sshd[20536]: Invalid user marcus from
Jan 12 19:46:29 regulus sshd[20538]: Invalid user newsletter from

8 login attempt in a 30 sec time frame

The geographical location of the scans origin is particularly interesting to me. It highlights the interconnectedness of the Internet and shows that even a single, personal web server on the public Internet is exposed to some level of real risk. A larger organization may find geographical location of attacks useful data when compiling threat profiles or when implementing restrictions on incoming network traffic.

To better understand where these SSH login attempts were orginanting, I wrote a Python script to lookup location of IP address and map them on Google Maps. I originally got the concept for this from a friend of mine, Chris Long's website ( The script, creatively named,, uses to fetch the location data for each IP read in from a text file. It then parses the information and creates a .kml (Keyhole Markup Language) file that can be read by Google Maps.

My current iteration of this script relies on reading from a static file called ip.txt. This file is generated by a simple bash script that searches the server authentication logs for every instance of failed SSH logins.

/bin/cat /var/log/secure* |egrep '(failed|Invalid)' | egrep -o '([[:digit:]]{1,3}\.){3}[[:digit:]]{1,3}' > ip.txt

Bash script to generate ip.txt

The output from is a .kml file called location_data.kml. This file can be imported to Google Earth or read by Google Maps API. A cron job runs the bash script and on daily.

Google Maps example: Source: view-source:


More »