Skip to content

Instantly share code, notes, and snippets.

@boxysean
Created December 10, 2012 15:03
Show Gist options
  • Save boxysean/4251087 to your computer and use it in GitHub Desktop.
Save boxysean/4251087 to your computer and use it in GitHub Desktop.
Router Hackz: Wireshark

A report back from Tuesday's hack sesh:

  • We started off by installing Wireshark on our computers. Sae and Sarah run OS X 10.8 (Mountain Lion) which does not come with X11, so they needed to install XQuartz before launching Wireshark. (Sae, there you go, that's how you do it buddy.) We then dived in and played around with the basic features. (X11 is a cross-platform windowing system like Aqua and Cocoa are windowing systems for OS X. Lots of open source projects use it for their GUIs because it allows to code one solution for many platforms. The trade-off is the applications don't have the Apple/Windows look-and-feel that we all expect.)

  • Using Wireshark is a bit like a scavenger hunt. There's a lot of information flowing on our local networks, the fun part is trying to figure out what is interesting. Robbie and Peter, connected to the standard NYU wireless network, started to capture packets with dynamic webpages streaming election updates. They saw a lot of web traffic racing in and out of their own computers despite it appearing not much was happening. (Wireshark looks like this, btw http://cdn.ttgtmedia.com/digitalguide/images/Misc/WiresharkSS3_lg.png.)

  • Peter tried to sniff some of Robbie's packets floating in the air, but Ali explained to us all the PEAP (the wireless security protocol that NYU uses) does mutual authentication, so we can't read the packets in the air that were not intended for us to see. Wireshark doesn't show packets that it can't decrypt. We talked about WEP and open networks that don't do mutual authentication, versus WPA that does.

  • Peter wanted to know why his bittorrent downloads slow to a crawl when his roommates go on Skype (or something like that). Basically he wanted to know what happens when a network is flooded with TCP and UDP packets -- does the TCP connection get hosed? TCP packets have a larger communication overhead than UDP because every TCP packet received must be confirmed by the recipient, triggering an extra packet. Sarah and Peter tried this scenario by launching netcat client / servers on the command line to create really simple ad-hoc servers. Sarah ran two clients -- one TCP at port 8080 and one UDP at port 8081 -- spamming packets with payload "hi" as fast as they could to Peter's corresponding TCP and UDP servers. Results were inconclusive, but we did clog the wireless network. :) (Read more about netcat: http://en.wikipedia.org/wiki/Netcat)

  • When we were wrapping up, Sarah and I continued to chat a bit about projects that are really good at both being "art objects" and "network concepts". These two projects in particular are pretty inspiring: http://wiki.daviddarts.com/PirateBox http://transparencygrenade.com/.

Okay. I'd love some feedback:

  • Let us know if this is TMI or too technical or whatever.
  • Ask questions if you want me to clarify or expand on something.
  • I'm looking for inspiration for the next router hackz meetup topic.
  • Send out your own experience of the hack sesh if you'd like!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment