Slashdot Mirror

← Back to Stories (view on slashdot.org)

Reverse Engineering an MPEG Driver

Posted by CowboyNeal on from the how-we-do dept.

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."

11 of 275 comments (clear)

  1. Free, but not Free by Dancin_Santa · · Score: 5, Insightful

    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.

    1. Re:Free, but not Free by Svartalf · · Score: 5, Informative

      In actuality, they released everything BUT the driver info for the MPEG stuff. They handed the 2D and 3D over to the DRI and XFree86 people- Alan Cox was working on making the drivers all nice and clean up until recently.

      From what I got from my contacts at SiS and VIA when I was working on set-top box designs using their chipsets was that the stuff was being held to an NDA because of contractual reasons. My ignorant guess would be that there's something with regards to the MPEG patent licensing that prevents the details being released for piracy prevention reasons because the use of these accelerators would enable real-time/near real-time transcoding of DVDs, etc.

      This is not to say that I'm right, or if I am, that it's a good reason.

      --
      I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
  2. Er... by slackingme · · Score: 5, Funny

    But does it ru--
    Nevermind, no points to spare :)

  3. Re:Software decoding works fine by MikeFM · · Score: 5, Informative

    My lil epia box does better than my parents faster Wintel box at playing dvd's and vob's. Sure a lot of that is because MPlayer and Linux are so much better but you're mistaken if you think the epia systems don't have the muscle for the job. If they could enable the hardware decoding it might even make the playback better. They also run much cooler, more energy effecient, and quieter.. something that IMO is a mark of quality.. not of being 'cheap'. Besides, price compare the CPU's.. you'll find they aren't that cheap. :)

    --
    At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
  4. why do it by hand? by MikeFM · · Score: 5, Insightful

    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.
  5. C vs. assembler by Atario · · Score: 5, Funny

    From the article:

    Also some of the logic could be detemined by decoding binary flag fields. For example:

    push gVIAGraphicInfo
    push 805476C3h
    push fVideo
    call ioctl

    Can now be decoded into the rather more readable:-

    ioctl(fVideo,
    _IOR('v', //118 192+3,
    VIAGRAPHICINFO),//0x805476C3, &gVIAGraphicInfo )

    Oh yeah. Much more readable.

    --
    "A great democracy must be progressive or it will soon cease to be a great democracy." --Theodore Roosevelt
  6. Not quite done yet by wowbagger · · Score: 5, Insightful

    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
  7. Re:Cool! by El · · Score: 5, Funny

    Better yet, lets reverse engineer the Windows drivers instead of the Linux drivers, so then they'll get mad and discontinue Windows driver development altogether! Yeah, right...

    --

    "Freedom means freedom for everybody" -- Dick Cheney

  8. Re:Is this reverse engineering? by Anonvmous+Coward · · Score: 5, Funny

    "You honestly think that simply living in Italy is enough to protect him? Have we learned nothing from reading Slashdot?"

    I've learned that paranoia is an epidemic.

  9. Re:Is this reverse engineering? by yellowstone · · Score: 5, Informative
    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.
    Well, this is definitely not a 'clean room' reverse engineering.

    To do a clean room implementation, you need to have two teams:

    1. The first team digs into the implementation, and produces a document specifying the interface.
    2. The second team uses the specification produced by the first team to create an implementation.
    This is a clean-room implementation when the only communication between the two teams is via the specification: A) No one who sees the original implementation works on the new implementation and B) No one who works on the new implementation looks at the original implementation
    --
    150 Opening BINARY mode data connection for slashdot.sig (129323052 bytes).
  10. Re:NOT reverse engineering by orv · · Score: 5, Informative

    The copyright statement in the driver from via states:-

    * Permission is hereby granted, free of charge, to any person obtaining a
    * copy of this software and associated documentation files (the "Software"),
    * to deal in the Software without restriction, including without limitation
    * the rights to use, copy, modify, merge, publish, distribute, sub license,
    * and/or sell copies of the Software, and to permit persons to whom the
    * Software is furnished to do so, subject to the following conditions:
    *
    * The above copyright notice and this permission notice (including the
    * next paragraph) shall be included in all copies or substantial portions
    * of the Software.


    It's just that they didn't actually release the code for the driver. So the port doesn't need to be a proper clean room reverse engineer.