You can read Maria’s article in PDF format here. It’s well worth your time.

Click here to read the article.

John’s direct but conversational way of speaking quickly grabbed my attention. One point that he made while summarizing scrum methodology to the audience took me a little off guard (around 13:02):

“It’s in your face every day, and that’s kind of what agile does for the workplace: it focuses you on what you’re doing that day, [so that] you can’t come back in two weeks and say, “Oh, yeah, I forget to do that.” So that’s, I think, the biggest benefit for motivating, and the biggest way of getting burnt out because you’re always . . . working on these tasks that need to get done; you feel like a dog. So there needs to be a balance [in] that you need to be working on your agile, but you also need some free time . . . you need to do it [development] in a sustainable way.”

As I told him in later in an email, I was somewhat taken aback to hear “burnout” and “agile” in practically the same sentence — if anything, I would have expected “waterfall” or some other top-down methodology to receive the blame, as it typically does. But could agile practices which claim to promote sustainability actually be a catalyst to such a state? In response, he excerpted a section from the Agile Manifesto’s “Principles“:

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

As is evident from distress cries such as this example, by-the-book scrum doesn’t necessarily always uphold this ideal. It is easy to see how sprint followed by sprint can be, well, rather breathtaking, and just as there are no silver bullets for blossoming productivity, there are no easy answers for solving the problem of burnout. (As one commenter in the aforementioned link quips, perhaps “sprints” should be treated more like “laps.”)

At work, we use an integrated tracking solution to log tasks and bugs, plan sprints, perform reporting, and hold each other accountable. After the novelty of using the system had worn off, I remember wondering if this task-based approach helps or hinders productivity. Obviously, we need to have a formal, collaborative way of keeping track of and sharing work between developers and managers, yet despite the fact that I crave the satisfaction of ticking off a completed task as much as the next guy, there is little fulfillment in doing so repetitively unless it is part of a clearer, larger goal. (Fortunately, my good employer goes through great lengths to ensure that we do not reach a point of feeling mechanical, for which I am blessed… still, it is an interesting topic of discussion.)

Perhaps mostly because for me, structure hasn’t really ever been a problem. I am a detail-oriented person by nature and I thrive in an organized environment (okay, so my computer science compadres might use a stronger adjective). I’m a self-described productivity enthusiast, sporting over 1,000 completed tasks last year on RTM alone, combined with countless tasks tracked with the aid of Grindstone 2 weighing in for a total of 853 hours, 48 minutes, and 44 seconds in 2010. My Google calendar is color-coded and is an essential part of every day, yet I am ever searching for new ways to optimize my efficiency. Heck, I even made myself a nice long list for Christmas break:

So what’s the point of mentioning my lame Christmas break routine? Simply to point out that I’m learning, slowly, that as nice as it is to plan out the minutia of every day, this can easily lend itself to burnout (thankfully, a trip to Chicago to visit old friends, at the end of my vacation, re-awoken and livened my otherwise tired spirit). There is a beauty and a freedom to “unstructure,” not to mention the health benefits of it. John’s talk this past week merely put a different spin on this truism, studying the phenomenon in the environment of software development.

Simple pragmatic antidotes that agile typically employs are the discouragement of working late, encouragement of scheduling deliberate time off, and/or providing days to research a topic or technology of personal interest. In short, leading a balanced life seems to be the most basic step to combating burnout. What I would like to suggest in addition is perhaps a more immediately applicable solution; that is, that simply recognizing the value and meaning in workplace relationships can breathe life into a schedule that has become mundane.

I would venture to say that most of us — certainly myself — who became developers did so not out of an overwhelming desire to interact with other humans, deal with team conflicts, and put up with the formalities and processes that are necessary to successfully deliver larger projects. Rather, we signed up out of love for hacking meaningful code, only to inevitably discover that communication skills are just as important as technical qualifications to the success of a software product. What if now, instead of kicking against this system — I speak principally to myself — we viewed it as our greatest ally to keeping our job satisfaction?

Holding each other accountable is not only a way to keep the current iteration on track, it is also an opportunity to recognize that even the most motivated of developers need mutual encouragement. It can be a reminder that the deepest motivators are not salary or even feelings of accomplishment and worth, but rather a more fundamental solidarity with humankind in an environment that fosters the formation and growth of inter- and cross-team relationships.

John’s argument acknowledges the necessity of this accountability, praising agile for promoting it on a daily basis, but also cautioning that a danger lies in allowing a methodology that we typically use to free us from top-down rigidity to become merely a means of dispassionately squeezing out more effective results.

I couldn’t have asked for a better departmental senior seminar (CSCI 481 at Hope College) this semester. On the first day of class, the professor shared his “vision” with us of a Dropbox(TM) client for the Nokia N900 mobile device and those like it — the N900 is a smartphone which runs a Debian-based Linux variant — whereupon he essentially allowed us to devote nearly all of our in- and out-of-class time to the project for the entire semester! The result is a working implementation for the Linux desktop (not yet ported to the N900), that I am excited to describe in brief here.

Project Goals

So why another Dropbox client for Linux? The following goals set DBoxTop apart from the crowd:

• Tight integration with the operating system. Existing projects that aim to bring Dropbox to Maemo/MeeGo-based devices tend to act as file viewers from a client program of some sort. This was deemed to restrictive for our purposes, so we set out with the intention to implement our client as a Virtual File System (VFS) using the Linux GVFS/GIO libraries.
• Storage-sensitive caching. Since our primary targeted platform is a mobile device with limited storage, we want to allow the user to limit the size of locally cached files, and the program to smartly maintain this cache by replacing files that are used least often with incoming files that need to utilize the limited cache space.
• Local/remote transparency. The user should be able to interact with (e.g., move, copy, delete, rename, etc.) all files on his or her Dropbox account in exactly the same manner whether the files are cached locally or remotely. A natural corollary (don’t you love it when your textbooks use that phrase?) is that files should only be downloaded for operations that truly need them to be local, such as opening a file to read or write.

Finally, we the source code developed in this process is and will remain a part of the open-source domain.

Architecture

Writing a virtual filesystem for DBoxTop requires a daemon in C that implements a common interface by which the operating system interacts with the filesystem. The way that this works in GVFS is that the first time a file is requested, a master daemon determines which implementation-specific daemon to launch by extracting the protocol out of the URI (smb://, ftp://, trash://, dboxtop://, etc.). The master daemon spawns the appropriate child daemon, whereupon the file viewer (Nautilus, a command window, or any other program accessing the file using the GIO API) communicates with the child daemon to present the files for user interaction.

Essentially, the role of the child daemon is to present the filesystem in a unified format, so that the view does not have to care about its specifics. The inherent beauty in this system is that a program needs only to know the URI for the file or folder to access and manipulate it. The diagram below illustrates the GVFS daemon system.

As an example, suppose that some application wishes to display the directory at dboxtop://Public/fun. Assuming that this is the first time in the user’s logon session that a file on this protocol has been accessed, the process looks something like this:

1. The master GVFS daemon launches the appropriate (dboxtop) daemon and calls do_mount on it so that the child daemon can perform appropriate setup. At this point, the dboxtop daemon performs initialization tasks.
2. The master calls do_enumerate on the daemon to request the list of files, passing the path /Public/fun.
3. The child daemon requests a file listing from Dropbox (more on how this is done later), and returns the list of file and directory names (e.g., “image1.png,” “text_file.txt,” and “another_folder”).
4. For each of these names, the master daemon calls do_query_info on the child (dboxtop) daemon, requesting metadata such as the mime type, icon, creation date, and the size of the file.
5. The user now sees the file listing, complete with metadata, as if the files were part of the local filesystem (indeed, this is the whole point of a “virtual” filesystem). The communication flow for file operations is very similar to listing files.

At the time of this writing, an SDK for the Dropbox API has not been implemented in C, so rather than spend the entire semester writing such as SDK, we chose to use the pre-existing Dropbox library written in Python. However, this meant that we either had to interop the Python and C code, or run the two components in isolation and set up Inter-Process Communication (IPC) between them. After some experimentation, we chose the latter route, using DBus for the IPC.

Although this was likely the easier route and leads to a nice separation of work into a “frontend” (the gateway for accessing the Dropbox SDK and displaying a simple widget-like UI) and a “backend” (the GVFS daemon supporting the dboxtop:// protocol), it somewhat muddles the distinction a bit. For while the frontend does provide the user interface as would be expected, it also acts somewhat like a backend by providing a service for the daemon. The interaction between the two can be seen from the illustration below.

The internal circular components represent modules which have specific responsibilities. For example, on the backend side, each operation can be separated into a local and a remote part: first, if the file is local, perform the operation on it in the cache; then, request that the frontend tell Dropbox to perform the same operation remotely. Needless to say, if a file is not local, then the first part is skipped and only the remote operation is performed.

The frontend also contains a few internal components with distinct purpose. The most prominent of these are a multi-threaded upload and download manager, and a “cache trimmer” which manages the free space in the local cache. The latter is used whenever a file operation needs to add one or more files to the cache, from the user either copying a file into the Dropbox folder from an external location (some other location on their hard disk), or requesting that a file be opened (in which case it needs to be downloaded first). What the user sees of the frontend looks like this:

The icon on the left launches user preferences, and the graphic on the right “connects” or “disconnects” from Dropbox (in actuality, this means mounting/dismounting the DBoxTop filesystem daemon).

The frontend is responsible for all authorization/authentication dialogs which grant the application access to the user’s Dropbox account, a preference dialog, and a multi-task progress indicator for downloads (although this workflow is currently impeded; see the end of this post for details). Its primary purpose however, as mentioned before, is to provide a bridge from the backend to the Dropbox API.

While the backend does not provide a graphical user interface, the user initiates interaction with it whenever he or she performs an operation on files. The avenue by which this is typically done is either via Nautilus or the command window, as shown.

The screenshot above also hints at our goal of local/remote transparency, or that all of the user’s files are visible regardless of whether or not they are cached locally.

Development Process

Despite its drawbacks, separating the project in this way led to a rather intuitive way to organize teams. Since we had a small class of 7 people, it was decided that three persons (Ryan Alfuth, Benjamin Bockstege, and myself) would work on the backend, while the remaining students (Elijah English, Jeff Largent, Nathaniel Martin, and Ryan Veneklase) would implement the frontend and its components.

We practiced a loose form of the scrum agile development process, meeting once or twice a week for 10-15 minutes with our advisor, who kept track of progress for grading purposes and played a large role in sprint planning.

An Incredible Experience

This is the kind of class that I can’t get enough of. Furthermore, the fact that it is not only a class that I dig but that it also counts as academic credit tickles me all shades of neon colors.

I learned a great deal about working with a team this semester. Perhaps the highlight of my experience was successful paired programming, which taught me a great deal about the value of patience and being willing to teach others to “fish” rather than “fishing” for them. It also brought the backend team very close together as a unit, with each contributing significant personal investment in time, code, and brain cycles. I also witnessed a transformation in at least one member who, as we encouraged his contribution and kept him looped in on decisions, rapidly took ownership of his involvement and could scarcely contain his enthusiasm for the project.

Of course, managing a project also comes with a great deal of frustration, especially when there is a large lack of communication intra- as well as inter-team. While functioning as the informal project lead — which occurred mostly because my zeal for the project, combined with a lack of leadership initiative at the onset of the project, positioned me for the role — myself in addition to a few other of the more involved folks were constantly faced with the problem of giving the remaining members of the group opportunities to be actively invested in the process, yet under the constraint of looming deadlines. More often than not an empty-handed team-mate forced one or two people on the team to pick up the slack for the other, just to be able to meet the sprint deadlines.

In summary, while I feel that overall we were successful, we certainly could have improved our communication and fostered greater contribution as a whole. For one thing, we should have agreed on a weekly, set schedule by which we could have met as an entire team to hash out the latest problems and solution proposals, argue over intelligently discuss important architecture decisions, and so on. This would have kept us much more responsible to each other. As it were, our meetings did take place fairly frequently, but they were ad-hoc, somewhat unstructured, and often lacked key developers.

Current State & Future Goals

As of December 2010, DBoxTop is fully functional as a Dropbox client for the Linux desktop. There are, however, a few major tasks which we were not able to complete in the course of a single semester. What follows is a shortened version of DBoxTop’s to-do list:

Continue remedying the asynchronous downloading

“Whoa, wait,” you say, “you mean to tell us you didn’t plan for asynchronous downloading of files!?” Not to worry: the system was indeed designed for this from the onset of the project, but a few technical complications got in the way of achieving fully-asynchronous file downloads that can happen concurrently and without blocking the user interface. We do have a functioning multi-threaded download manager on the frontend and requests to download a file from the backend are also performed on separate threads. Without delving into too much detail here, the problem currently lies in the way that the DBus message pump ties into the Glib UI loop, which has the consequence that while a service call (from backend to frontend) is waiting to return, the UI thread is effectively frozen.

The solution to this dilemma is to implement two-way IPC so that the frontend can asynchronously notify the backend when a download has been completed; however, this requires that the backend also provide a DBus “server” and have the threading backbone to manage download requests and their state. We made a significant amount of progress toward this end, but we ended up running out of time and had to revert the code back to its synchronous state for the product demo.

Port to the N900

This is, of course, a major goal of the project. It should not be too difficult, however, since the N900 runs a 2.6.x Linux kernel, sports a Gnome-based desktop with GVFS/GIO support, and can run a Python interpreter. We’ll need to cross-compile the binaries and tweak a few things here and there, including using Maemo’s or MeeGo’s adaptation of Qt for our user interface.

Authorize the application with Dropbox

In order for normal accounts (those other than our developer accounts) to be linked to our application, we must submit our source code to Dropbox for its “blessing.” The next goal naturally follows…

Provide installation packages

This is especially wanted since what we have now is nearly ready for installation and beta preview by end-users, at least on Ubuntu systems.

Since the backend is already setup to build with automake/autoconf, this shouldn’t be tremendously difficult. We intend to package the backend and frontend separately, but have them inter-dependent and/or create a metapackage called “dboxtop” which depends on both “dboxtop-backend” and “dboxtop-frontend.”

Although it is obvious that we have a long way to go on the project, my colleagues and I are extraordinarily excited to have been a part of the inception of the project, and satisfied with the progress that we have been able to make towards the end result. I look forward to see it evolve into a fully-featured client.

Resources

• Technology information
  • Dropbox for developers
  • GVFS, GIO library references. Note that as of this writing, there is not a lot of information here about GVFS (a rather glaring frustration to us, too). My recommendation is to download the source code or check out that of DBoxTop to gain an understanding of the details.
  • DBus homepage
  • PyQt homepage
• DBoxTop information
  • Product homepage
  • Final presentation, delivered December 9th, 2010
  • Developer’s documentation

Credits

Out of all who contributed to the DBoxTop project this semester, special thanks go to teammates Ryan Alfuth and Benjamin Bockstege for their stellar work. In addition to his technical contributions, we also owe Jeff Largent for the DBoxTop logo. Nate is officially the Qt guru for the project, Eli wins the award for most on-topic late-night phone-calls placed, and the prize for the best humor and team spirit goes, as always, to Jeff. Thanks guys!

Want to Help?

If you are interested in being a part of the DBoxTop project moving forward, feel free to contact our adviser.

What follows is a list of my essentials, as I see them, after a year of solid trial by fire. But before I do, I’d like to share a few lessons that I’ve learned, which are:

The Golden Rule(s) of Productivity Tools.

1. If it isn’t dead simple to use, universally accessible, and wicked fast, throw it out — no matter how cool or 1,000-point-oh is seems.

2. Technology isn’t the end-all-be-all key to making you a productive person. Be willing to keep what works, throw out what doesn’t, and go old-school (i.e., with manila folders and notebooks) where it works better for you. The best solution is likely a happy medium between new and old.

3. Keep what works, but don’t be afraid of change, either. It takes a continual amount of experimentation to find what works with your learning/organization process. Moreover, the continual process of improving is what keeps things interesting.

Your future productive self will thank you, even if it’s super boring.

1. Google Calendar + RTM plug-in

This one goes without saying. Zoho offers a decent alternative, but I love GCal for its simple interface to a large array of features. I keep a color-coded set of calendars (Work, School, Personal, and Critical), making sure to set up repeating events for each of the classes in my schedule the day before school begins.

2. Firefox + Three Essential Plug-Ins

Combined with Faviconize and PermaTabs Mod, my email accounts and calendar (along with the to-do list) stay front-and-center at all times. I’m pretty sure I picked up this combo from Lifehacker, and I’m glad I did. Launching multiple hoggish desktop apps instead is less than pleasant.

Although Xmarks is universally useful for synchronizing bookmarks (across IE and Chrome, too, if you use them), it comes in particularly handy for keeping track of links and tidbits that I’m collecting for the next big research paper.

3. Dropbox

I don’t know how I lived without it, but Dropbox has become indispensable to my workflow in more areas than just my education. The best part about this application, I am convinced, is because it doesn’t force you to modify your standard pattern of working: just save to the local Dropbox folder, and everything is synced automatically and with tiny overhead.

I keep a folder for the current school year along with subfolders for each class that I’m taking. Working across multiple computers is a snap because I don’t have to think about where the files are stored — and if I want to walk to the library and print out the essay I’ve just labored over, there’s no need to bring a laptop, because all of the data is accessible from the web.

I even synchronize my time spent working remotely, logged with Grindstone, using Dropbox. It rocks.

4. Remember the Milk

RTM is an online to-do list on steroids, but its brawn isn’t immediately transparent thanks to a simple and effective user interface. I’ve evaluated a range of alternatives from Task Coach, to TeuxDeux, to Toodledo, but none strike the same balance of features and simplicity of use as Remember the Milk offers. I logged and completed more than 1000 tasks over the course of my Junior year, and felt considerably more productive.

The process I used morphed a bit from the first to second semester, but here’s a rough overview:

1. If the professor has been kind enough to plan all of the assignments, homework, and due dates into the Syllabus, these go directly into RTM within the first week. It’s a lot of typing, but it pays off in the time it saves by having all assignments due for the the day centrally located.
   The keyboard shortcuts that RTM features are well worth the effort of learning — and it doesn’t take much; they’re all single-key. Here’s the combination I use most:
   1. t – create a new task
   2. d – set the date
   3. (repeat above as needed)
   4. m – manipulate multiple tasks
   5. s – tag all selected
   6. n – deselect all
   7. (repeat 1-6 for all each day up to a month in advance, for  each class)
2. Each week, I do my best to review both my calendar and all tasks on RTM two weeks in advance, making new tasks for the current week as necessary (for the larger projects) in order to meet deadlines for homework assignments and such that are logged with current tasks. This way I am reminded to start the longer-term projects early; the dailies are performed and checked off in a normal fashion.
3. The prior two steps enable me to practice a greatly simplified morning  routine, consisting of a brief visit to my Calendar and a click on the RTM drop-down for the day.

Notes: Digital or Not?

My sophomore year, I grabbed Office Ultimate 2007 on UltimateSteal, and immediately made a snap decision to take all of my notes on my laptop. As excited as I was for OneNote, though, my plentiful math and science classes soon made the effort to keep digital notes more trouble than it was worth, particularly after the “shine” wore off of the experience.

Actually, I still don’t use the program since I dropped it, even though I regard it as a brilliant app — and have at least one coworker who swears by it.  The reason that I take notes by hand these days is primarily because of the following:

1. I am a Computer Science student. I spend way too much time at the screen already, and staring at a laptop to take notes isn’t that profitable when I am inevitably doomed to trudge back to the dorm and spend a late evening hacking code.
2. Although I’m now running Office 2010 with all of the Live features that the suite has to offer, I’ve found that text documents synced with Dropbox does just as well for the vast majority of notes that I do need to store digitally, with much less overhead.
3. There is an inexplicable, intangible feeling of investment in the note-taking process when it is done by hand; a satisfying sensation of seeing ink splash across the page that a keyboard can’t even come close to replacing.
4. My laptop weighs a bazillion pounds. I hate lugging the thing around with a passion, and the loud, rattling CD tray invariably revvs up during class.

Of course, taking notes with a laptop comes with its advantages: at the top of the list is that typed notes are much faster to take than handwritten ones, closely followed by pros of instant searchability, and easy backups.

This year, I’m considering adapting the Cornell Note-taking method.

Wrap-Up

Though the combination of tools and processes above is from last year, since I am please with the way that it turned out, I’m going to do my best to resist the tech-junkie’s urge to try new services and stick with what works for my senior year.

Do you have a better process or combination of technology that works better for you? Let me know in the comments.

IMPORTANT: Play it safe… please backup your data before continuing!

1. Ensure that Grindstone is fully closed (right click on system tray icon and select Exit).
2. Create a folder named “Grindstone 2,” or something you can remember, in your Dropbox folder on the local file system. For example, C:\Users\<YourName>\Documents\My Dropbox\Work\Grindstone Mobile\Grindstone 2.
3. Locate C:\Users\<YourName>\AppData\Roaming\Grindstone 2 and copy its entire contents to the folder you just created in (2).

   

   Before continuing, ensure that the folder that you’ve just copied contains, among other files, config.gsc2 — this is the XML file that Grindstone uses to keep track of settings, tasks, segments, and all your other saved information.

4. Rename the original (in AppData\Roaming) to something like “Grindstone 2 Backup.”
   
5. Download Junction, a free utility from Microsoft. We’re going to use it to create a soft link from the original location to the new location within Dropbox’s jurisdiction, so that Grindstone 2 will link to the data indirectly when the program starts, without being able to tell the difference. NOTE: Normal Windows links (i.e., .lnk files to a folder) will not work for this purpose.
6. From wherever you extracted Junction, hold down shift and right-click in Explorer, and select “Open command window here.”
7. Now, execute the following instruction to create the soft link (note that this is actually all one line):
   
junction "C:\Users\<YourName>\AppData\Roaming\Grindstone 2" "C:\Users\<YourName>\Documents\My Dropbox\Work\Grindstone Mobile\Grindstone 2"

   The result of this command is shown below:

   

8. To verify that this worked, you can cd to Roaming and execute dir. What you see should resemble the following:
   
9. Now for the true test: launch Grindstone, and verify that all your profiles and tasks are intact.

Repeat this process on any other computer that you wish to sync Grindstone with. Note that in order for the tasks to be synchronized, it will be necessary to shut down Grindstone at the end of your work day since Dropbox cannot sync files that are in use.

KillJoy is a mobile TCP session monitor which allows for termination of specific sessions in addition to complete denial of service to a specific computer on the network. In its current implementation, KillJoy is designed to run for and has been tested on the Nokia n810 Internet Tablet, running Maemo 4 (Diablo); however, a minimalistic version also runs as a desktop application (both are experimental works in progress).

KillJoy’s main strength and distinction is that it does its work as a normal computer on the network, without needing to redirect all traffic through itself or act as a gateway in the form of an Intrusion Detection System (IDS). Instead, it accomplishes this via TCP and ARP packet injection. Furthermore, KillJoy is a flexible tool, allowing both interactive (manual) termination of sessions and automated control based on preset rules.

Some initial goals for the project included:

• Maximum portability (application must run on a handheld device)
• The ability to perform passive monitoring and when necessary, assert active control over an existing TCP session on the network without elevated privileges, provided that access to the network itself has been established (i.e., the network is unprotected or we have previously retrieved the network key)
• The capability to automatically detect and terminate sessions (connections between a local client and a remote host) that have been previously detected and “blacklisted” by the user
• The capacity to perform higher-level protocol analysis, in order to distinguish between traffic which uses the TCP protocol (Bittorrent, Windows Media, etc.). This goal was not achieved by the culmination of the project.

My original intent for this project was to be able to selectively exclude certain traffic from a network; ultimately this goal was achieved to the extent that the user can control the who, but not the what, since time did not permit the integration of higher protocol analysis into the product. Of course, it should go without saying that the project was intended for educational, and not nefarious purposes!

The implementation makes use of the technologies listed below. For more information on the development details, please refer to the presentation linked to at the end of this post.

• Python 2.5
• Scapy from SecDev.org (provides low-level packet inspection, modification, etc. from Python)
• The PyGTK library (Python bindings for the GTK+ user interface toolkit)

Let’s look at an example of KillJoy’s workflow on the Nokia n810. The application begins to monitor network traffic via packet inspection immediately upon startup, listing all detected sessions for every local IP on the network.

The above menu is displayed upon right-clicking on a session (note that right-clicking on a target, or the parent node in the treeview will display only the second and fourth options, as these operate on child sessions for the local IP in aggregate).

Upon selecting the Terminate session menu item, the remote connection is forcibly terminated. To accomplish this, KillJoy hijacks the TCP session and sends in-sequence RST packets to the remote host. (Note that the session will only be removed from view when a certain amount of traffic has passed without any further indication that the connection still exists.)

Towards the end of the project, I began to realize that KillJoy was not picking up all traffic from the wireless access point; instead, the only packets being detected and processed were only those sent from or received by the device itself. This was puzzling, since the network interface is supposedly capable of being dropped into monitor mode — and indeed, executing iwconfig wlan0 mode monitor returns without any error, but tcpdump is still not able to pick up any third-party traffic thereafter. Eventually this led me to the conclusion that the NIC hardware on the Nokia n810 (or the driver used for it) is not able to support true promiscuous / monitor mode, so to work around it, I implemented the capability to perform a Man-in-the-Middle (MiTM) attack on any number of devices on the network in order to view their traffic. Here’s how this might go:

1. The user, realizing that not all traffic is being picked up by the device, uses KillJoy to perform an ARP scan on the network to discover all active devices.
2. From this list of local active devices, the user chooses a subset of IPs to add to the MiTM list.
3. From this point on, an ARP spoof attack will be performed and maintained on each of the devices, positioning the attacker between the devices and the gateway, thus allowing him or her to view all traffic previously undetectable.
4. When the user exits the application, KillJoy automatically restores the ARP caches on all the devices from the MiTM list, resulting with (hopefully) minimally-detectable intrusion.

Note that it is also possible to manually specify and IP for ARP redirection if the IP is known.

I tested this approach with an off-the-shelf Netgear home router and it worked well; however, on other networks the ARP attacks were thwarted by presumably up-to-date router firmware intended to prevent such a well-known attack. However, the features provide an additional level of built-in capability to the user, should the program be used on a network device that does not support full promiscuous monitoring of packets.

Finally, without further jabber: a demo of KillJoy in action! Warning: mild drama.

For a more detailed and complete description of KillJoy’s features, or to inspect its internals, please refer to the following links:

• Download page
• Presentation (as given at Hope College on the 21st of April, 2010)
• Installation & Getting Started Guide (PDF, 2MB)
• Source code (SVN, archive [0.1])

This is none else than the inspirational tale
Of an email which nearly failed
Sadly, to complete circulation
And put to rest wild and undue speculation

Concerning a certain well-meaning patron
Not, however, given to over-communication
Being as he is confined to a life of hard labor
(That is to books, and lectures, and paper,)

His good grandparents, in deep concern
Wrote an epistle to discern
The awful state which was ensuing
Their grandson and consuming

His life, a poor and gruesome fate
Concluded many, when the hour drew late
Rumors and speculations abounded
Greedy siblings his possessions divided

And when no reply was forthcoming
Cries and wails were heard in mourning
But hark! When all seemed despairing:

Projects were finished!
Deadlines were met!
Homework completed!
Procrastination repressed!

And the email lives! No more is it lost
Deep in the clutches of a cluttered in-box
In fully good health, the prodigal taps a reply
Sipping on coffee, which he has come by

Honestly, thanks to a generous donation
(Which, by the way, deserves admiration)
And hereby sends you his thanks, and moreover
Proof of existence, which can’t be glossed over

For chances of further survival is bleak
Due to threat of examinations, arriving in two weeks
And if God deems to stay their vicious attack
His kind roommates have offered to pick up the slack

But before he goes down in glorious battle
He feels it his duty to surface, and prattle
A bit, taking respite to thank his dear benefactors
Grateful for patience, thankful for prayers

As always, hoping to be reunited
Unless, of course, school his fate has decided
But until then he wishes his love to send…

And with that
this belated reply
does hereby
come to an end.

Product home page: http://www.sothink.com/product/swfquicker/
Download page (today only): http://www.giveawayoftheday.com/swf-quicker-4-7-holiday/

I’ve put together a quick video to show you how to extract the installer file from its Giveawayoftheday wrapper (useful since the wrapped executable will only allow installation today). The video also demonstrates importing a .SWF as a new project. Running length: 5:32.