Slashdot Mirror
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."
In all seriousness, what's the point? It's not like Xine on any decent machine using Xv is going to look or work any better using this hardware decoder. CPU is cheap.
Driver code is the biggest liability that a device maker has. It earns no money, it costs quite a bit to make, and it must be written multiple times for multiple platforms and operating systems.
Via's reluctance to free the driver software is pure evil. They sit like slavemasters on the code and hold it hostage as if it were a servant or slave.
Even if the reverse engineering works out and the code runs equally well as the enslaved code, what will become of the original unfree code? Will that unfortunate code be relegated to living out the rest of its days in slavery? Sadly, I think the answer is affirmative.
Who will fight for the rights of software? I only wish the FSF was more vocal about the Freedom of Software that they purportedly base their ideology upon.
The silly thing with all of this is that the drivers and support for this card that result from the reverse engineering will ultimately result in more sales. It seems so counter-intuitive for VIA to resist this.
Why not use a program that automaticlly takes the binary and builds a C program from it? You still have to pick through the logic to give things helpful function/variable names and refactor but it'd save the step discribed here. In the past when I've reverse engineered binaries that is the type of tool I used. Any good reason for doing this by hand?
This still begs the question.. why not just release the damn source? If we can reverse engineer the drivers what would keep the competition from doing so? Why harm your customers for a false sense of security?
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
Hardware decoding allows for much higher resolution video. Furthermore, specialized hardware typically have more accuracy when decoding the stream. There's additional features too: you can allocate, say, more bits for dynamic color range, fractalize regions that have semi-random "noise" distribution (like tree leaves from a distance) and so on that can improve video quality (to help eliminate obvious artifacts). I am not saying all hardware decoders do this, but these are some advantages. It's very analogous to having specialized 3D hardware to handle graphics rather than "letting the CPU do it".
Join Tor today!
It won't produce the same code. Different compilers do things different ways. In the end the binary produced will run the hardware the same way and that's the goal.
Very clever, but I thought reverse engineering worked on a functional level.
He did do functional analysis to make it work. He understood what the thing was doing. If he did not, his code would never have worked. He made little doodles and what have you to make it clear to himself. Now it's in C, the diagrams are much easier to make, though we can be sure he's going to share his diagrams as well. That way other people can make nice software too.
IANAL, but I don't think the source code is legally safe if VIA wants to go after it.
I don't know why you think that. He could have had his computer tell him what it was doing instead of using IDC, no? It's not like he dumpster dived code like old Bill Gates did BASIC. He understood what the code did and reimplemented it himself. Even if he did have dumpster dived code, he could use that to make a functional diagram and then use that to write new code and the results would be the same.
If there is a legal problem with this, there should not be. Why should people be afraid to understand what their machines do and then share that information? So someone else can make money of evryone else's ignorance? Shit, no one would be able to get anything done that way.
Friends don't help friends install M$ junk.
Well, he has done the first part of a reverse engineering process - he has worked out, by inspection of the target, what is being done.
However, he now needs to write the specifications for the hardware, and publish THAT, so that somebody else, somebody who has not seen the binary driver, can write a program based upon the specifications.
Should this not be done, then this code, while interesting to individuals, would be pure poison to anybody who has any intention of distributing this code in a commercial way (e.g. a distro).
And writing a specification for the chip, by inspecting the code, is far more difficult than simply reverse compiling the binary.
www.eFax.com are spammers
With the ever-increasing clock speed of our CPUs, what is the point of having a hardware MPEG decoder? I understand that p2-400 is sufficient to play DVD-quality movies. The amount you spend on the hardware decoder could have been better spent on memory or video card or CPU or whatever. Now, a hardware encoder would certainly be useful as encoding is still very CPU-intensive. I was contemplating a tivo-like box with a hardware encoder. Does anyone know if hardware MPEG encoders are supported on Linux?
___
If you think big enough, you'll never have to do it.
Can you imagine what would happen to VIA's sales if they somehow offended M$ and M$ retaliated? They could keep VIA in the dark or give them bogus SDK info so that their hardware would not run well under Windblows. Even witholding a dinky little check here is damaging. Harware makers that defy Microsoft are doing something heroic and should be rewarded.
Once enough hardware makers tell Microsoft to shove off, it's all over. In fact, it's already all over. Windows already enjoys the bad reputation they deserve. When you buy something for Windows, the odds of it working are only marginally better with the goofey M$ binary driver than they are with a free driver. There are some exceptions to this rule, like winmodems and crappy little digicams, but the gap is closing quickly. Everyone will be better off when stuff can be chosen on grounds of technical merit rather than M$ favor.
Friends don't help friends install M$ junk.
You honestly think that simply living in Italy is enough to protect him? Have we learned nothing from reading Slashdot?
First of all, it's just a small wrapper library that is comparatively easy to reverse engineer.
Second of all, there is a library we can reverse engineer.
Third of all, the guy is using the VIA forums to spread the word, so VIA obviously knows about this, and they haven't sued.
To me this rather looks like they were waiting for someone to reverse engineer this, because they couldn't release the sources themselves for contractual reasons. Don't just assume people are evil, maybe they didn't have a choice and did what was in their power to give you the means to help yourself.
I believe that distribution of this code would be illegal, since it is a derivative work based on VIA's library. I haven't seen VIA's license, by typically those licenses prohibit redistribution, reverse engineering, and disclosure of any trade secrets.
The reverse engineering itself is probably still legal, arguably, if it is done to enable someone to write software that interoperates with the decoder. To be safe, I would assume that it's probably better to write such software for an operating system that VIA doesn't support - QNX, for example. (One could argue that the BSDs' ability to run Linux binaries voids the interoperability argument if one were to write a BSD driver, but what do I know?).
You should also make sure that the person writing the final open source code hasn't seen VIA's decompiled source. Typically this is done by having one person or team reverse engineer the code, document the hardware, and toss the hardware documentation over the wall to the driver team.
"..Typically, only requests from companies developing product for sale will be approved.."
/. ?
Has the article submitter actually asked them instead of going by a press release and venting on
Gotta start somewhere though - an opensource driver is a good place to start building your superior functionality on.
Who taught anyone that dissassembling someone's proprietary code and doing a line for line port then publishing the result was in any way legitimate?
The better question is: Who decided that the "clean room" approach is actually necessary? Answer: a bunch of ultra-paranoid lawyers at Compaq who were about to piss off Big Blue (deep pockets, lots of lawyers and extremely protective of IP) in a big way and wanted to make absolutely completely sure that there was no way their project could be called a copy.
I don't think it's at all clear that copyright law makes so-called "clean room" reverse engineering necessary. AFAIK, a court has never stated that source code reconstructed from a binary is considered a copy, or even a derivative work. Copyright law does not prevent you from reading something, learning from it, and creating something else based on what you learned. It may be that a court would rule this a derivative work, rather than an work of independent authorship, but it's highly questionable since courts have already said that only the expressive, not the functional, part of code is copyrightable.
It's very clear that clean room reverse engineering is sufficient. It's far from clear that clean room reverse engineering is necessary.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
What kind of message does this kind of thing send to hardware manufacturers that might want to release drivers for Linux? Write a driver for our OS and we'll reverse engineer it and do what we like!
I'm not sure this is the best method to attract quality drivers for Linux.
A Mini-ITX Linux system that used the functionality provided by this driver, had a 3-second BIOS bootup time using Linuxbios, plus a PCI TV tuner card with hardware MPEG-2 encoding, would be a pretty impressive media center.