Reverse Engineering an MPEG Driver

An anonymous reader writes "Following on from the recent spate of reverse engineering articles, there is an interesting summary of the reverse engineering of a binary only Linux driver. The driver is for the integrated MPEG decoder on VIA's popular EPIA-M boards. At the moment VIA has not publicly released the source code for the MPEG chipset on these boards and will only make the code available under NDA saying that "Typically, only requests from companies developing product for sale will be approved." As a result this is holding back development of open source tools (e.g. xine, mplayer, vdr) that would be able to make use of the interesting hardware on these boards."

Comments

Is this reverse engineering?

[bromoseltzer]

He took the binary code and inferred a C language program that would produce the same code. Very clever, but I thought reverse engineering worked on a functional level.

IANAL, but I don't think the source code is legally safe if VIA wants to go after it.

-mse

Re:Is this reverse engineering?

[dmayle]

Unfortunately, to be safe, you have to load the library in a debugger, and are only allowed to look at the data being sent to the chip, or returning from the chip. That would be reverse engineering the driver. However, unless there was a licensing agreement prohibiting it, dissasembling the driver to learn how it works is a legal way to learn how to use the chip, so long as your end goal is not writing a drop-in replacement for the library. Think of it like this: Reading from a book on programming is learning, and legal. Copying from a book on programming (whether word for word, or paraphrasing) in order to write your own book on programming is illegal.

Does it work yet?

[FryGuy1013]

To me, it just seemed like a general description of the RE process that people able to RE already know. EPIA M boxes are already good for small PVR boxes using mythtv when a Hauppauge PVR card is added (and a larger power supply). If the MPEG decoder can be used, I'm sure that even the lesser models of EPIA will be able to be used.

Why a hardware decoder? - Because - It's a VIA

[Chordonblue]

Obviously you've never used VIA processors before. They are notorious for their slow FPU's. In fact, before their latest top-of-the line model - the Nehemiah, their FPU's of previous models always ran at HALF CLOCK. Ouchy.

But, even at full speed a similarly clocked Celeron kicks it's ass in every which way. That said, high performance is not the stated purpose of the Centaur/Via CPU. Its low watts, coupled with the decoder make for an excellent all-around box. I've built around 7 or 8 of these myself and they are excellent for what they are designed for (think: mom and dad or net terminals, not Half Life 2).

I have a few of these floating around the school here now as basic net access / workstation terminals and they are hugely popular - especially in light of what they replaced (AMD 300's). There's nothing like tearing apart some ancient computer and putting one of these boards in it. 90% of the time, it's simply cavernous in there (so much space!)

Last week I put one in an Aptiva and realized that if I was an enterprising person (read: man with a Dremel) I could have fit TWO of them in there as a dual workstation! :O

So to sum up, they're small as hell (you have to see it to believe it), simple, fun, easy to configure, but don't plan of using them at the next Fragfest 2003 (c)

Re:maybe, but not for that reason

[homer_ca]

Another possiblity is that Macrovision copy protection is enabled or diabled in the driver (maybe even by flipping one bit). Macrovision is the analog copy protection mandated by the DMCA. So can't let the open source community break their one bit encryption.

I believe this is the TV encoder chip used by the EPIA-M and the VT1622M is the one that supports Macrovision.

Re:Free, but not Free

[captaineo]

Here are two legitimate reasons a hardware company might withhold driver code:

1) They differentiate high-end and low-end versions of the same product in software only. I think Nvidia and some storage vendors do this - they sell the same card for $200 and $400, but the driver disables certain features on the $200 part. If they released the source someone could easily find a way to re-enable the "high-end" features on cheap hardware, thus erasing the product differentiation. (which would force the company to sell only the more expensive part, and everyone loses)

2) Software-based copy prevention, a la DVD CSS, or software-based restrictions, like Macrovision. (I know at least one video card company won't release driver source because it would be obvious how to stop Macrovision from being enabled when a video player requires it)

I'd say 2) is slightly less legitimate, but I have no problem with reason 1). I'd rather be able to buy cheap but limited hardware than not have the option at all.

Dxr3

[daserver]

Lets not forget the hardware mpeg2 decoder - dxr3. A lot of people have worked on this and it has resulted in a very decent driver. It has had absolutely zero help from sigma. There is even hacks to make it display rgb directly to your tv, bypassing the crappy composite and svideo.

Re:Free, but not Free

[ckaminski]

Remember a year or two ago when turbo-charging your Celerons was all the rage? Intel fixed this with an ondie switch that was lasered shut at the factory to stop this. Nothing, not one thing, is preventing a manufacturer from adding $0.10 to a part for a hard-wired switch that makes a $200 part into a $400 part. If it's in software, you're still taking the chance some enterprising developer is going to figure it all out, and ruin your party.

Most people, especially saavy ones, are not loathe to trying out new drivers. MANY are very afraid of taking soldering irons to their $200 parts.

-Chris