Category Archives: Reverse Engineering

Brainstorming and case studies relating to craft of software reverse engineering.

Reflections On On2

I read something in the past few months which noted that, in this day and age, the ultimate phase of any tech startup’s business plan is to be purchased by Google. Viewed through that lens, On2 is about to live the dream, even though they existed years before Google, years before most people even knew what a search engine was.


Assorted logos of Duck, On2, and Google

So Google has announced its intention to purchase On2. Wow, it feels like the end of an era. It seems like I’ve had some relationship with On2 for the entire 9 years I’ve been into multimedia hacking. Something that got lost in yesterday’s coverage and commentary was that On2 started life as the Duck Corporation, also a codec company. During this period, they largely focused on gaming applications. But I’m pretty sure that RAD Game Tools kicked them out of that market with their Smacker and Bink technologies. However, files encoded with the Duck’s multimedia codecs were among the first I studied back around 2000-2001. So that always makes me sentimental.

Continue reading

Remembering Fravia

I was reading up on this year’s Pwnie Awards — hoping that no nominations dealt with any software that I’m directly involved with — when I noticed someone named Fravia was up for a Lifetime Achievement Pwnie.

I remember Fravia, or really, his site. Back in 2000 when I became interested in reverse engineering due to its necessary if tangential relationship to understanding multimedia technology, I took to the web to search for tips. Fravia’s site was one of the first I found. It was apparently a goldmine of RE knowledge. But I could never know for sure– I always found the place packed with impenetrable jargon without a glossary in sight.

Further, the site seemed to focus primarily on how to reverse engineer relatively simple stuff– copy protection schemes and key generators. The targets I was — and remain — interested in tend to involve reasonably complicated mathematical algorithms compiled into machine code. Different domain, different challenges.

I think Fravia’s site was where I read an interesting document for programmers who wished to thwart reverse engineers. One tip was to load your program with blocks of NOP instructions. Apparently, these are harbingers of self-modifying code and in the context of counter-intelligence, a reverse engineer will go nuts anticipating and seeking out such aberrant code.

Fravia is no longer with us, having passed away in May of this year. His site lives on, as engimatic, baffling, and aesthetically unsophisticated as I remember it being 9 years ago. It seems to have shifted focus somewhere along the line to studying how search engines operate. I wonder if all that RE knowledge is lost forever (or perhaps buried deep in the internet archive which doesn’t make it much more useful).

In a way, Fravia was an inspiration for me– In addition to multimedia tech information, I wanted to publish data on practical reverse engineering matters so that other people could get up and running as quickly as possible without having to wade through weird jargon.

Camp Luna

I remember when the Mono people first announced the Moonlight project for Linux that would interoperate with Microsoft’s Silverlight. They claimed that Microsoft would release a special binary codec pack that would allow Linux users to play back their proprietary media codecs. However, this codec pack would not be allowed for use in any other application, like FFmpeg or GStreamer. How are they going to enforce that? Or so I wondered. Tonight I learned how.

I started investigating the API of the binary codec pack blobs a few weeks ago. I got as far as figuring out how Moonlight registers the codecs. Then I lost motivation, in no small part because there isn’t that much in the blob that I would deem interesting (perhaps one method for keeping people from sorting out the API). In the comments of the last post on the matter, people wondered if the codec pack included support for WMA Voice, which is still unknown. I can’t find any ‘voice’ strings in the blob. However, I do find references to lossless coding. This might pertain to Windows Lossless Audio, or it could just be a special coding mode for WMA3 Pro. Either way, I’m suddenly interested.

So I looked for interface points in the Moonlight source. Moonlight simply loads and invokes registration functions for WMA, WMV, and MP3. The registration functions don’t return any data that Moonlight stores. Moonlight doesn’t appear to load (via dlsym()) or invoke any other codec pack functions directly. So how can it possibly be interfacing? The only other way the interaction could flow is if the codec pack shared library was invoking functions in Moonlight…

Oh, no… they wouldn’t do that, would they?

Continue reading

Silverlight Codecpack

I was visiting ossguy’s blog today when I noticed that he took a small break from the usual “Free Software Über Alles” rhetoric to post a useful investigation of the Microsoft binary codec pack that corresponds to Moonlight, Linux’s free implementation of Silverlight. At first, I was surprised to hear that this codec pack was finally available– I didn’t think it was going to be generally available until Moonlight’s official release. A little digging revealed that Moonlight 1.0 was officially released yesterday. I wondered why I hadn’t seen anything about this on any major Linux news sites yet.

Apparently, no one cares.

Well, I care, insofar as this is another way to study some codecs. I think it’s really slick that the codec pack is one monolithic, relatively small, binary blob that contains all the proprietary codecs needed to support Silverlight. ossguy’s post details 2 more-or-less direct download links:

I see that compn is already on the case, identifying the precise codec formats that this blob is designed to handle: wma1, wma2, wma3, wmv1, wmv2, wmv3, wmav, wvc1, and mp3. So, really, nothing interesting for our cause. Almost all of those formats are already supported in FFmpeg. The one that isn’t — WMA3 — is in progress via a Summer of Code project. Who knows? Perhaps this codec pack could yield some new intelligence. But I tend to think the previous binary decoder released for Linux — packaged with Linspire — was pretty thorough in its presentation of symbols.

This codec pack is pretty thorough in the symbols department as well. Run ‘strings’ against the blob to see the ASCII strings. Filter the output through ‘c++filt’ as this will demangle (official technical jargon) the C++-style names:

  strings file.so | c++filt

And if you want to disassemble the binary, here is a little something I wrote up regarding the bare essentials of ‘objdump’ as applied to reverse engineering work.

At the very least, I can see this codec pack being useful for hooking up to FFmpeg in order to gather a baseline for profiling to see how FFmpeg’s decoders stack up. Further, I should be able to use it to decode reference samples to verify how close FFmpeg decodes, e.g., WMA 1/2 data to the original.

Whatever the case, I have started a MultimediaWiki page to describe the API.