Debugging Javascript in Firefox

I was playing around with PwdHash today, and I realized I couldn’t see the debug output (created with calls to the built-in function “dump()”). This was sufficiently complex to remedy that I’m making a note of it here.

Open a new tab and enter “about:config” for the address. Right click on any of the existing entries and select “New -> Boolean”. Create the following two booleans, set to true:


This ends up putting these two lines into prefs.js, which lives somewhere in your profile directory:

user_pref(“browser.dom.window.dump.enabled”, true);
user_pref(“javascript.options.showInConsole”, true);

Don’t edit that file while Firefox is running or your changes will be overwritten. Also, using this ‘about:config’ method causes your changes to take effect right away, so no need to restart (or lose all your tabs!). This output goes to the unix console (stdout or stderr), so make sure you run your browser from a terminal. The Error Console viewable from the Tools menu displays more sophisticated errors. I’m only interested in printf()-style output for now.


Bluetooth hacking has come a long way

Recently I learned just how much of the Bluetooth protocol is performed by the Bluetooth adapter itself. This was disappointing for me, as I wish to hack about with the relevant encryption and authentication mechanisms. Life is not all bad, however. Cambridge Silicon Radio (CSR) makes some Bluetooth radios that read their firmware from an onboard flash chip, and some enterprising individuals (, darkircop, PDF slides) have figured out how to extract, disassemble, reassemble (potentially modified), and reprogram these devices.

The motivation for all these people was to create a general-purpose sniffer, enabling creation of bluedrift. I would like to see the creation of some open source firmware for these devices, so I don’t have to bog through disassembled binary to find where to insert my own code. 🙂

Also, an interesting paper is Bluesniff: Eve meets Alice and Bluetooth

IMAP over SSL with Dovecot, and mbox vs maildir

I’m playing around with hosting my own little IMAP server to act as the repository in which I put all my old email I’m too stingy to delete. I ended up choosing Dovecot because it seems simplest, and because the only way mail will get into these folders is when I drag it there in my client. `aptitude install dovecot-imapd` did the trick, and even generated SSL certs by default (although they have localhost.localdomain as the machine name, so I will end up changing them).

I ran into one snag: mbox vs maildir. I have some of my really old email sitting in mbox files, so I chose mbox as my default folder format during installation. This turns out to add a few challenges: mbox folders cannot house subfolders. Thus, in Thunderbird, when I create a new folder, it becomes a message-housing entity if I name the new folder with letters and numbers, but it becomes a subfolder-housing entity if I name the new folder with a trailing ‘/’. This took some Google time to figure out.

It’s fine with me if I can’t have messages and subfolders in my own folders, with the exception of the Inbox. CMU apparently uses maildir format and so I’m used to all of my subfolders hanging off of the Inbox. I’m probably going to switch to maildir before I do The Import.