US Cellular POSTer

Sometime over the past two weeks one of my coworkers sent me a text message via US Cellular's text message sender. After thinking about it, I wanted to write a program that could do the same thing. Now, I know I could simply write an email client to send to a US Cellular email address, but where's the fun in that?
So, I began my journey. My first suspicion (and hope) was that the US Cellular page used HTTP POST to transmit its information. I fired up Ethereal (now called WireShark) and began sniffing packets. Sure enough, there was a POST to usc.ztango.com:
POST /uscwmss HTTP/1.1

Host: usc.ztango.com

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

Accept: text/xml,application/xml,application/xhtml+xml,
text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: http://usc.ztango.com/uscwmss

Content-Type: application/x-www-form-urlencoded

Content-Length: 148

sesId=10F6896FF1DE72C40A
&MSG=From%3A+**********%0D%0AHey+buddy.
&ADDRESSES=**********
&FROMADDRESS=**********
&MSG_TMP=Hey+buddy.&count=122
&tc_agree=on
HTTP/1.1 302 Moved Temporarily

(NOTE: I added linebreaks to the above body for clarity. In actuality the parameters are al in one line.)

Really what we're interested in is the body of the POST message, which I'll copy and paste to make things clearer:

sesId=10F6896FF1DE72C40A
&MSG=From%3A+**********%0D%0AHey+buddy.
&ADDRESSES=**********
&FROMADDRESS=**********
&MSG_TMP=Hey+buddy.
&count=122
&tc_agree=on

(

NOTE

: I have erased the phone number in the request for confidentiality reasons. This number can be any 10-digit US Cellular number)

Looking at the text, we can break out the parameters of the request:

• sesId
• MSG
• ADDRESSES
• FROMADDRESS
• MSG_TMP
• count
• tc_agree

I can't claim to know what all this means, but here's what I've been able to decipher:

sesId - A session id generated by US Cellular to determine delivery status of the message. If you send a message from the US Cellular page, a resultant page will display showing the delivery status of the message. This is more of a guess than anything. For the purposes of this program I'm just going to keep using the sesId I grabbed from the sniffed packet.

MSG - Ahh, the interesting part. This is the actual message to be transmitted. Tthere's some code on the page to automatically prepend the message with the string "From:**********" This is one of the things I didn't like about the page, and we'll just leave it out of our messages entirely.

ADDRESSES: The US Cellular number to send this message to. Note the parameter name is ADDRESSES, plural. I'm assuming there's a way to send the message to multiple phone numbers, but I've never tried it.

FROMADDRESS: For all intents and purposes this field is worthless. It is used in the page code to generate the "From: **********" header on the message. When you receive a message from the US Cellular gateway, however, it always has the same default from number (0001114444). Again, this is a bit of guesswork on my part. We'll continue to include this parameter simply because I've never checked to see if its absolutely necessary (I guess US Cellular may check to ensure this is a valid phone number).

MSG_TEMP: Again, I believe this is another worthless parameter. My theory is that this parameter is passed along to the results page after the message is sent to display the message to the user. We'll continue to send this field along as well, for posterity's sake.

count: This is the number of free characters left in the message, with a maximum of 132. Basically, this parameter should be 132 - (number of characters in your message). Again, I think this is for the results webpage that gets displayed after the message is sent (and therefore probably not necessary).

tc_agree: This is the Terms and Conditions checkbox flag. If you don't check it, then you can't send a message. Again, we'll keep this always set as true.

Really, that's it. Its relatively simple. So now all that needs done is to write a client that can send HTTP POST messages to a given address with specified content. I wrote my first client in .NET with C#. .NET provides a class to do HTTP POST messages, so I literally wrote like 15 lines of code to get it to work. This was with everything hard-coded, but the proof-of-concept was there.
So, about a week later I decided to re-write the client in Cocoa for OSX, and add a GUI. If you've never written for OSX before, GUIs are drop-dead-easy (just like .NET with Visual Studio). So creating a window with a button, two fields and a text-box took maybe two minutes. The gotcha, however, is that OSX provides no HTTP POST message classes. There's a generic HTTP class, but no specific way to do POST. Therefore, you need to fill out the headers and create the message yourself.
I'm really lazy, so the idea didn't appeal to me. I Googled around for something that would do POST for me, and it didn't take long before I had a winner. Fritz Anderson (author of Step into XCode, and contributor to MacTech) had a sample article covering this exact issue. So, after reading that article and the prior as well, I heinously stole Fritz's FAWebPostQuery class to use in the client.
The rest is history. I have a desktop client I can use to send messages to any US Cellular customer. I don't have to pay 10 cents per message, nor use the keypad to punch in numbers. I've toyed with the idea of integrating with Address Book, but I don't know if this project has sparked my interest enough to warrant the added energy. At any rate, it was a fun little app to write (especially since I didn't have to do any of the POST wrangling).