Ad-blocking and whyfirefoxisblocked.com

Recently it [came to the attention of the Digg masses](http://www.digg.com/software/Why_Firefox_is_blocked) that some slimy SEO guy was advocating web site owners block *every* Firefox user simply because Firefox allows ad-blocking plugins, and doesn’t provide web site owners with any way to block users of such plugins.

I find this incredibly silly for a number of reasons. The number of Firefox users who use such plugins is likely very small. By blocking *all* Firefox users, you not only keep the ad-blocking users away (who most likely wouldn’t click on your ads anyway), but also the much larger number of users who *might* click on your ads. Mmmmkay…

Even if he’s doing this out of principle, or to make a point, he apparently doesn’t realize that *every* popular browser has ad-blocking software available. See below.

Personally, I’ve realized that I’m completely web ad blind. After 10+ years of web browsing, I’ve subconsciously conditioned myself to ignore all web advertising, unless it’s something truly obnoxious like Flash ads with sound, etc.

That said, this guy has inspired me to install both ad blocking software, and plugin to change the browser’s user-agent string to get around silly browser-specific filters (although if a site resorts to blocking certain browsers, do you really want to support them?).

### Ad Blocking ###

Firefox: [Adblock Plus](http://adblockplus.org/), also available from the Firefox plugin directory.

Safari: [PithHelmet](http://www.culater.net/software/PithHelmet/)

### User-Agent Changing ###

Firefox: [User Agent Switcher](https://addons.mozilla.org/en-US/firefox/addon/59)

Safari: built in, enable Safari “Debug” menu by entering the following on the command line:
defaults write com.apple.Safari IncludeDebugMenu 1

Update: the ad-blocking debate got picked up by [at least one mainstream newpaper](http://www.nytimes.com/2007/09/03/technology/03link.html), surely causing a surge of new Ad-block users… not quite what the slimy SEO guy had in mind. Karma?

Mystery solved: iTeaHAL

I’ve been getting strange messages in my system and console logs, or when executing certain applications from the command line. Notably iMovie and Skype:

iTeaHAL: Entering...
iTeaHAL: Not iTunes, exiting.

And when executing iTunes, I get this:

iTeaHAL: Entering...
iTeaHAL: Early startup...
itea_hijack_init: result: 0
iTeaHAL: Early startup done.
new_AudioDeviceAddIOProc:0x2281b68
link added
iTeaHAL: Late startup...
{length = 6, capacity = 6, bytes = 0x000a95c4a60e}
itea_fx_init: result: 0
itea_menu_init: result: 0
iTeaHAL: Late startup done.

If you have no idea what “iTeaHAL” is, this sounds rather ominous… something’s hijacking my iTunes?! It also didn’t help that I noticed this soon after using my laptop (if only for about 30 seconds) on [“the worlds most hostile network”](http://defcon.org/html/defcon-15/dc-15-faq.html) at DEFCON 15. I thought perhaps this was some kind of trojan backdoor that was piggybacking off of iTunes Music Sharing or something.

It turns out it’s nothing quite so evil.

Google turned up nothing except other people also wondering what the hell iTeaHAL was. Then I tried finding files named iteahal: “find / -iname iteahal*” also turned up nothing. I knew those strings must be stored somewhere, so next up was a grepping of the entire drive: “grep -arsi iteahal /”.

Success! Other than the system and console logs, the following files were found to contain “iteahal”:

/Library/Audio/Plug-Ins/HAL/iWow.plugin/Contents/Info.plist
/Library/Audio/Plug-Ins/HAL/iWow.plugin/Contents/MacOS/iTea

It’s the [SRS iWOW](http://www.srs-store.com/store-plugins/mall/iwow-plugin.asp) iTunes plugin from SRS Labs that’s supposed to make crappy laptop and computer speakers sound better (it actually does a decent job)

Apparently when an application loads audio plugins (like iTunes, iMovie, Skype, and other audio applications), it tries to load the iWow plugin, which detects whether or not it is iTunes, and spews all this debug information to the console.

Skype outage

Users of the popular VoIP network, Skype, have been experiencing widespread outages for more than a day now. And of course thanks to Murphy’s Law I happened to pick today to try to get my family set up on Skype.

So far I’ve heard three theories as to what is going on.

– Skype says the problem is [a deficiency in an algorithm within Skype networking software](http://heartbeat.skype.com/2007/08/the_latest_on_the_skype_signon.html), whatever that means. After reading a little about the [great lengths Skype goes to](http://www1.cs.columbia.edu/~salman/skype/) in order to obfuscate their network protocol and prevent reverse engineering, it wouldn’t surprise me if they spent more time protecting the protocol than making sure it works well…

– A [Microsoft update caused the outage](http://blog.tmcnet.com/blog/tom-keating/skype-outage.asp).

– A [remote DoS exploit](http://en.securitylab.ru/poc/301420.php) that was published on securitylab.ru was responsible:

#!/usr/bin/perl
# Simle Code by Maranax Porex ;D
# Ya Skaypeg!!

for ($i=256; $i>xCCCCC; $i=$i+256){
    $eot=‘AAAA’ x $i;
    call_sp();
}
exit;

sub call_sp(){
    $str="\"C:\\Program Files\\Skype\\Phone\\Skype.exe\" \"/uri:$eot\"";
}

Now, I don’t know much about Perl, Skype, or Windows… but I can tell you this little piece of code generates a series of strings containing a Windows path to the Skype.exe followed by a parameter starting with “/uri:” and ending with reaaaallly long strings of A’s:

"C:\Program Files\Skype\Phone\Skype.exe" "/uri:AAAAAAAAAA...AAAAAAAAAA"

…starting with 256 copies of “AAAA”, incrementing by 256 until it reaches 0xCCCCC (that’s 838,860). The problem is, the code doesn’t do anything with the strings, it simply assigns them to a variable and continues on with the next iteration.

Edit: actually, the condition in the for loop, “$i>xCCCCC;”, effectively always evaluates to true, thus the loop will repeat infinitely. The “correct” condition would have been “$i<0xCCCCC;". Yet another sign this thing is fake?

If it were actually complete, it would be a really simple command line argument [fuzzer](http://en.wikipedia.org/wiki/Fuzz_testing): basically executing Skype.exe with varying length “uri:” arguments. And if, in fact, this type of thing could take down the entire Skype network, well, Skype definitely needs to put more effort into the security and robustness of their program, rather than trying to prevent reverse engineering of their protocol.

Perhaps leaving the tool incomplete was a deliberate attempt by the writer to demonstrate the vulnerability exists without quite providing a working tool, or perhaps the exploit is a hoax. I don’t know Russian, so I can’t tell if there’s more information on securitylab.ru.

It will be interesting to see what the real reason for the outage is. Of course, with the Skype protocol so locked down, we may never know what the real reason is…

Update: [according to Skype](http://heartbeat.skype.com/2007/08/what_happened_on_august_16.html), the outage was caused by the massive number of Windows machines rebooting and reconnecting to Skype after a Microsoft update, and a flaw in Skype’s “self-healing” ability. Microsoft effectively DDoS’d Skype…

multiwhich

The “which” Unix command lists the location of the first matching executable in your PATH. The GNU version of “which” has several extra features including the ability to display all matching executables in your PATH, not just the first. This is useful for finding duplicates, etc. Unfortunately, whatever version of “which” is included in Mac OS X (and MacPorts) doesn’t have these extra features.

A quick Google search didn’t turn up anything, and I was in a shell scripting mood when I needed it, so rather than downloading and compiling GNU which I whipped up my own, “multiwhich”:

#!/bin/sh

for PATHDIR in `echo $PATH | tr ":" " "`
do
    sh -c "ls -1 $PATHDIR/$1" 2> /dev/null
done

Simply put this somewhere in your PATH with execute permissions, and type “which command“.

One other accidental “feature” of this script is the ability to list every executable in your PATH. This is great for finding duplicates:

multiwhich | sort | uniq -c | sort -n

It’s probably not the most elegant way to do it, but it serves it’s purpose. Perhaps someone will find it useful…

Update: I modified the multiwhich script slightly to support wildcards like “*” and “?”. You can now do things like “multiwhich x*” to get all binaries beginning with “x”, etc.

DEF CON 0x0F

I had a great weekend in Las Vegas at [DEF CON 15](http://www.defcon.org/). Met lots of cool people, saw lots of interesting presentations, ate lots of good food, and spent way too much money doing it all.

Perhaps my favorite moment of the conference was when DEF CON organizer [Jeff Moss](http://en.wikipedia.org/wiki/Jeff_Moss_%28hacker%29) lured Michelle Madigan, the undercover NBC Dateline reporter, to a room full of thousands of DEF CON attendees, and well… watch for yourself…

Some of the more interesting talks I saw:

### Day 1 ###

– The Church of WiFi’s “Wireless Extravaganza”, an overview of their current WiFi and Bluetooth projects.
– Steve Dunker on police procedure.
– H.D. Moore’s “Tactical Exploitation” (also the talk in which the Dateline reported was outed).
– Jeff Moss on “CiscoGate”, the story of the Michael Lynn / Cisco / ISS / Black Hat debacle in 2006.
– David Hulton’s “Faster PwninG Assured”, using FPGA’s to crack Bluetooth PINs and WinZip / Apple DMG encryption.
– Johnnie Long on “No-Tech Hacking”.

### Day 2 ###

– Dan Kaminsky’s “Black Ops 2007”, various web vulnerabilities.
– Zac Francken’s talk hacking access control readers like HID Prox cards.
– Brett Neilson on modern radio scanning (which is inspiring me to get back into scanning).
– David Gustin overview of “hardware hacking for software geeks”.

[Joe Grand](http://www.grandideastudio.com/) one-upped himself with the DEF CON badges this year. Last year the badge was a PCB with two blinking LEDs. This year it has 95 LEDs that can display scrolling text or a P.O.V., and can be reprogrammed by the user using the two capacitive touch sensing buttons.

DSC01606.JPG

The PCB also has pads and traces for accelerometer and ZigBee wireless transceiver chips. It would have been awesome if everyone’s badge already had them… imagine 6,000 DEF CON attendees’ badges wirelessly transmitting their accelerometer data. With a bunch of receivers placed around the conference hall, you could make some pretty neat maps. Oh well, there’s always next year!

DSC01602.JPG
DSC01607.JPG