You may have noticed that the downloadable binary of the Firesheep add-on works only with version 3.6 of Firefox. The main branch is still incompatible with Firefox 6, but the latest Firesheep branch, (firefox5) remains very active and contributors are working toward making Firesheep compatible with newer versions of Firefox. I was able to compile this branch on Linux, but not on on Windows 7. Unfortunately, there were actually several changes in Firefox 4 that are incompatible with the original architecture and implementation of Firesheep.
New Add-on Manager
Firesheep calls the executable component firesheep-backend.exe (or firesheep-backend depending on the platform) which is packed with the add-on. To find the path of the executable, Firesheep needs to get information about the add-on through the add-on manager.
Firefox 4 introduced a new way to interact with the add-on manager and deprecated the previous one. The change is deeper than just calling a different function. Getting the path of the add-on now requires an asynchronous call instead of a synchronous function call. This can be a big change for most plugin architectures. Fortunately, Firesheep is very well structured and uses an event-driven architecture. This means that it can easily deal with asynchronous calls.
The Firesheep branch firefox4 fixes this issue (mostly in modules/Firesheep.js) in a way that is backward compatible with Firefox 3.6.
There are several radical changes in Firefox 4.0 regarding XPCOM. First of all, you can see in the Firesheep compilation instructions, that the add-on must be compiled against Gecko 1.9.2. But Firefox 4 uses Gecko 2. This is a major version change which is not compatible with Gecko 1.9.2.
- XPCOM elements must expose a new interface, so older XPCOM elements for Gecko 1.9.2 no longer work
- XPCOM elements must be recompiled for every new major release of Firefox. This is a maintenance headache with the new Firefox release scheme, where major versions are released every few months
This led Firesheep to change its back-end considerably. You can see these changes in the firefox5 branch. Firesheep dropped the custom XPCOM. It now uses the native Firefox objects to run the executable. The back-end writes its output directly to a temporary file and Firesheep tails the output.
As a result, the implementation of Firesheep is a bit more complex, but getting it to run on different platforms is easier. The new version of Firefox is compatible with OS X 64bit, which was not previously the case. It should also make it easier for Firesheep to work with newer versions of Firefox, because there is no longer a dependency on a custom XPCOM.
No binary release yet
Unfortunately, there is no binary release (the final XPI add-on) of the firefox5 branch available for users to download and install on Firefox. While I was able to compile it on Linux (32bit and 64bit) easily, I could not compile it on Windows (missing pcap-config, could not find my BOOST libraries, etc.). I’ve spent several days trying to compile the different branches on Windows without any success.
Because BlackSheep is largely based on the Firesheep source code, it suffers the exact same problem. I did not test BlackSheep thoroughly enough after Firefox 4 was released, so I did not realize BlackSheep no longer worked. I apologize to the users of BlackSheep.
I want to make BlackSheep available for Firefox 4 to 6. This should be possible by using the firefox5 branch of Firesheep, but I need to successfully compile this branch on Windows 7 first, which I have not been able to do despite my best efforts. I would be very grateful if a reader has a working Firesheep firefox5 version for Windows and could send it to me. I’ll then be able to update BlackSheep and release it to the public.
Leave a reply