More fun with OutputDebugString()

Those who haven't nodded off yet might find this an amusing use of a deep knowledge of OutputDebugString(). This is a Win32 interface to a message stream that a program can use to send information to a debugger ("can't open file", "connected to printer", etc.), and it's used by developers to see what's going on in software that's not easy to attach to a debugger.

When running a debug-message receiver, it's common to get bits of random chitchat from unrelated software - it's not uncommon that software is shipped without all the debugging stuff removed - but most of this time this is pretty limited, so it doesn't get in the way.

Enter "Microsoft Digital Rights Management" - when using the MusicMatch Jukebox to play (purchased!) downloaded music, it apparently uses some Microsoft DLLs to make sure that this content doesn't find its way out and about, and it's taken some steps to forestall running a debugger on them. This manifests itself with an absolute deluge of these messages streaming across the debugging monitor, many of them every second:

159c:**********************************************************************************************
159c:This breakpoint is By Design.  You are accessing protected content while running the debugger.
159c:This only occurs in Free builds - either use Checked builds or stop playing protected content.
159c:Hint: turn off protection of CD copied content in Windows Media Player by going to {Tools}{Options...},
159c:clicking the CD Audio tab, and unchecking Enable Personal Rights Management.
159c:**********************************************************************************************

I've found several Microsoft DLLs (including BLACKBOX.DLL) that do this, and it renders the debugging monitor positively useless. The annoying part is that running a debug-message receiver is not the same thing as a debugger, so it's really just entirely spurious.

I have to get my work done, so I am faced with either excluding a dozen pieces of music from my playlist, or Fixing The Problem. I chose the latter, and I was surprised that it took less than an hour to protoype a solution.

As asute readers of my Tech Tip on OutputDebugString may remember, this API function uses a Mutex to gain access to the debugging channel, and if there were some way to NULL that handle out, it might suppress the messages.

It works.

By disassembling KERNEL32.DLL, it was straightforward to find the offset of the Mutex HANDLE (plus a helper variable that said "we couldn't open the mutex, so don't try again"). Using this knowledge, it's possible to OpenProcess() on the MusicMatch process, then write updated values to these variables (NULL for the mutex handle, TRUE for the don't-try-again variable).

These offsets depend precisely on the version of KERNEL32.DLL being used, and even minor variations of this file have substantially different values - it requires reverse engineering on a case-by-case basis.

So now I have a tool that can disable OutputDebugString() for any process, and it's made life much easier. I'm going to release this tool once I have a bit more miles on it, and this includes testing with KERNEL32.DLL version other than 5.0.2195.6794 (the latest in Win2000).

Those who (a) understand this, and (b) could use its functionality should contact me offline to make arrangements for some testing.

Now: it's back to listening to Stevie Nicks and Gypsy - best 99 cents I ever spent.

Posted by Steve at December 12, 2003 09:03 PM | TrackBack