In part 1 of ‘jailbreaking the iPhone for UNIX geeks’: I touched on the jailbreak process and then covered installing the BSD Subsystem, SUID Lib Fix for the 1.1.3 firmware and fixing a small problem with the google maps ‘locate me’ application. I hope you enjoyed reading it, and now let’s jump right into part 2, and show off what the the jailbroken iPhone can really do.

For all of us UNIX geeks who purchased and love their iPhones, undoubtedly you have read about or heard about ‘jailbreaking’. At first it was a very complicated and possibly dangerous procedure to undertake, making it’s value questionable at best. But over time the jailbreak process for a 1.1.3 firmware iPhone, has finally matured to a ‘1-click-solution’. It’s reached a point where it’s easily done and also easily undone, so I decided to take the plunge and jailbreak my iPhone.

Sadly, I must preface the content of this post with the following statement:

I AM IN NO WAY RESPONSIBLE FOR YOUR IPHONE. JAILBREAKING WILL VIOLATE WARRANTIES AND SUCH, IF YOU CHOSE TO DO IT, YOU DO IT AT YOUR OWN RISK.

I am not going to go in depth into the actual jailbreak process, as I said earlier it’s a ‘1-click-solution’. I used the application called ZiPhone, available in both Windows and OSX versions, are available for download here. The method that I used, as I am a legitamite AT&T subscriber, was ‘Jailbreak’ only; if you are like me, there is no need to Active, or Unlock your iPhone. READ the included documentation, it’s straight forward and simple, however if anything goes wrong, see my disclaimer and their troubleshooting section.

Last night, as I was leaving the worst walmart super center in all of the world, I noticed a police patrol car behind me. The officer followed me out of the walmart parking lot, west on university drive and into a gas station parking lot. I was unaware that I had done anything wrong, so I wasn’t really paying any attention to the officer at this point. I went  about my business about to get some over priced gasoline and head home. The officer gets out of his patrol car and approaches me .. odd. I started to feel a little nervous, wondering what I could have done to warrant attention from the police at 10:30 PM on a Sunday night. I say “good evening officer, may I be of some assistance to you?” to which he responds that he needs to see my drivers license and insurance.

Wait a minute, you need to see what? .. why do you need to see those items? …. I was floored by his next statement. The officer informed me that I am driving a “suspicious vehicle”. Without even thinking about what I should do or say, I responded, “No I don’t, I drive a Nissan 350z .. it doesn’t say suspicious  anywhere on it.”  … thankfully his radio went off and he had to respond to a call of more importance, probably fresh donuts at krispy-kreme.

I still have no idea why I was considered suspicious .. but it sure felt good to pwn that cop.

In an earlier post, I covered some basic and a few advanced techniques that can be done with tcpdump and bpf. Today I would like to expand upon those ideas just a little more.

Recently I was tasked with examining some traffic captures, looking for some specific UDP traffic. In this case, UDP traffic with a source port greater than or equal to 1024 and a destination port equal to 80. So how did I achieve this task with tcpdump?

tcpdump -n(r or i) <pcap.file or interface> ‘(udp[0:2] >= 1024 and udp[2:2]=80)’ -s0

So what does all that really mean? It’s actually pretty simple. The four most useful bpf statments to remember in regards to udp traffic are as follows:

udp[0:2] = source port
udp[2:2] = destination port
udp[4:2] = datagram length
udp[6:2] = UDP checksum

So in this example, I am simply asking tcpdump to show me udp traffic with a source port greater than or equal to 1024 and a destination port equal to port 80 and set the snaplen to 0 (show the entire packet contents).

This concludes another look into the endless possibilities that can be achieved with tcpdump and a good knowledge of berkly packet filters. Have fun with this, and nerd it up.

Just a real quick tip today, while I get back into the swing of things, post-moving.

A friend of mine showed me a very useful utility called mergecap, which is included with the wireshark package (formally known as Ethereal). This is one of those “so simple it hurts” tools, that I wish I had known about years ago. So what is so special about mergecap? Well if you’ve ever had to deal with multiple capture files, you know what a pain it can be to search through them all. This is where mergecap comes in handy.

There are a few options discussed in the man page, but in it’s simplest form, from the command line:

mergecap *.pcap -w /path/to/output/dir/name.pcap

Now, you simply wait a few seconds and you will have a properly merged pcap file. I tested this method on a few pcap files gigabytes in size and mergecap only took about 10 seconds to do its job.

If you are like me, and do not have X or a monitor installed on your sniffing box, I suggest installing tethereal, which is the command line only version of the wireshark package. Mergecap is included in the wireshark-common portion of the required packages.

Enjoy this short little tip and as always have fun nerding it up.