Reverse Engineering an MPEG Driver 275
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."
Is this reverse engineering? (Score:5, Interesting)
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? (Score:4, Informative)
Re:Is this reverse engineering? (Score:5, Funny)
I've learned that paranoia is an epidemic.
C vs. assembler (Score:5, Funny)
From the article:
Oh yeah. Much more readable.
Re:Is this reverse engineering? (Score:5, Interesting)
Re:Is this reverse engineering? (Score:2)
well yes, what else do you want? (Score:4, Insightful)
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.
Re:well yes, what else do you want? (Score:3, Informative)
The coder and the diagramer should be different people for clean reverse engineering.
Re:Is this reverse engineering? (Score:2)
Re:Is this reverse engineering? (Score:5, Informative)
To do a clean room implementation, you need to have two teams:
- The first team digs into the implementation, and produces a document specifying the interface.
- 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 implementationRe:So he replicated the binary? (Score:2, Insightful)
Does it work yet? (Score:4, Interesting)
What about DMCA? (Score:2, Informative)
Or is it perfectly legal and VIA can not do anything about it? They seem to have an interest in suppresing such efforts though, since they've stated they are interested in revealing the code only to entities that want to make a buck off of it.
So, even if DMCA dosn't apply here, are there any chances they could be nasty about it? U-Boot
Re:What about DMCA? (Score:5, Insightful)
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.
Re:What about DMCA? (Score:2)
Re:What about DMCA? (Score:2)
- Reverse engineer anything
- Post a link to an article on reverse engineering something
- Follow said link and read the article
- Discuss the article
- Post a reply (ad nauseum).
Re:What about DMCA? (Score:3)
Free, but not Free (Score:5, Insightful)
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.
Re:Free, but not Free (Score:2)
At least it made me laughed.
Re:Free, but not Free (Score:3, Insightful)
Am I right? Or would companies not go for this?
Re:Free, but not Free (Score:5, Informative)
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.
maybe, but not for that reason (Score:3, Informative)
Re:maybe, but not for that reason (Score:2)
Re:maybe, but not for that reason (Score:5, Interesting)
I believe this [viatech.com] is the TV encoder chip used by the EPIA-M and the VT1622M is the one that supports Macrovision.
Re:Free, but not Free (Score:4, Insightful)
Re:Free, but not Free (Score:2)
It's a decoder, not an encoder, and the epia cpus are terribly slow at doing encoding.
Re:Free, but not Free (Score:3, Interesting)
But seriously, you bring up a good point. Companies that GPL or OSS their driver code are doing themselves a favor and saving a lot of the money that would be spent supporting the code later on. I hope that we'll see someone release hardware someday on an open spec with just an OSS reference driver so the community can build the driver from scratch on a new product. Initial sales might be a little flat, but that company could save lots of cash in the long
Re:Free, but not Free (Score:2)
Actually there are several GPL'd official drivers out there, but the only one I know of off the bat is some recent LKML traffic indicating that Promise GPL'd their pdc-ultra Serial ATA driver, and that it might be getting worked into the kernel.
Re:Free, but not Free (Score:5, Insightful)
Most hardware companies use off the shelf parts. They aren't designing the technology so much as lciensing it and marketting it. The ONLY reason they are able to make money off of their products is that they have something that Generic Q. Solderinggun doesn't -- they have the ability to interface these hardware chips with a computer. And all of that magic happens in the driver.
I've seen lies here that drivers don't make money, and this is simply ludicrous. Let's take a real world example: back in 1997, both Iomega and Miro (later Pinnacle) marketted an MJPEG video input box based off of a Zoran chip. Zoran made a very very nice chip capable of massive resolutions, dozens of colour modes and bus mastering and all kinds of kick ass stuff. However, Iomega skimped on their drivers. The result was a product that was totally unable to operate at spec, because the driver had a fundamental flaw that prevented it from capturing at 29.976. Savvy video users quickly learned to cap at 30.10, drop a frame, and save $100+ over the cost of the similar Miro card. However, no matter how much the Slashdot community would like to think otherwise, you can't make money selling to ONLY savvy users. Iomega promptly dropped support, even though late model drivers were FIXING the issues. Miro, on the other hand, made money off of their superior drivers for years to come. Those drivers made that money.
If Miro opened the source of their drivers, GPL or otherwise, nothing would have stopped Iomega from getting them, modding them slightly to include their hardware, and releasing them back to the community. After all, they're not selling them. Good for everybody, right?
No good for Miro, whose dilligence in driver manufacture has just cost them countless sales. Their hardware is now just the sale as the other guy's but sells for much more.
Why the hell do you want hardware companies to lose money for your hobby? Are you so vain that you really think your 3% of the marketshare is worth that much to the VIAs of the world?
Re:Free, but not Free (Score:2)
The drivers were so bad, they would often lock up the computer or crash Premiere after capturing 2 or 3 minutes of video. Total crap; we had to return ours.
Miro's worked fine, so it wasn't a problem with the computer.
Re:Free, but not Free (Score:5, Interesting)
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.
Re:Free, but not Free (Score:2)
Which would force them to sell the expensive part at a more reasonable price. They're charging $400 for a product they can sell with a nice profit at $200. Why should that be encouraged?
Re:Free, but not Free (Score:2)
I think we're just beginning to see these types of products emerge, but soon every product will follow this paradigm. As more and more menial tasks are automated, the costs of manufacturing plummet in relation to the costs of design.
I'd hate to see the day when the same refrigerator is artificially differentiated and priced based upon its energy efficiency, but I wouldn't
Re:Free, but not Free (Score:3, Interesting)
Most people, especially saavy ones, are not loathe to trying ou
Re:Free, but not Free (Score:3, Interesting)
I think this one fits this particular situation perfectly. If VIA can withold the one piece of the puzzle (hardware decoding) that opens the door to easy, cheap, upgradeable DVR boxes and license that piece to lots of different companies, VIA wins.
Re:Free, but not Free (Score:3)
Greed should be illegal? But you just said "If they can make a profit by selling the card for $200, they should sell it for $200". Surely making any profit at all is just being greedy, shouldn't they be forced to sell it at break-even pricing?
Of course, that doesn't leave any money in the coffers to pay for the R & D for the next product, so that next product might take a lot longer to ever be produced. On the other hand, if they had some
Re:Free, but not Free (Score:3)
As customers, we pay their wages. They must never be allowed to forget that.
Er... (Score:5, Funny)
Nevermind, no points to spare
CLE266.tgz mirror (original slashdotted) (Score:5, Informative)
Be nice to it, and check the original site after slashdot effect goes away.
irony (Score:5, Insightful)
the fist of M$ (Score:3, Insightful)
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 [microsoft.com] is damaging. Harware makers that defy M
Why do you say VIA resisted? (Score:5, Insightful)
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.
Cool! (Score:3, Funny)
Re:Cool! (Score:5, Funny)
why do it by hand? (Score:5, Insightful)
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?
Re:why do it by hand? (Score:2)
Links please?
A link to just that: Reverse Engineering Compiler (Score:5, Informative)
Reverse Engineering Compiler [backerstreet.com]
Re:A link to just that: Reverse Engineering Compil (Score:3, Funny)
Re:A link to just that: Reverse Engineering Compil (Score:2)
Looking at the examples provided with the decompiler, I'd say that the answer is obvious. The decompiled code bears little resemblance to the original C code, and is almost useless for understanding what it does.
This is not to say that a decompiler cannot (in theory) do a better job ...
Re:why do it by hand? (Score:2)
Decompilers have limitations of course but I think they're easier as a first step (usually) than working with raw binary or even assembly. Once you get a mixed C/Asm source it's much easier to clean the code up and refactor
Re:why do it by hand? (Score:2)
Re:why do it by hand? (Score:3, Interesting)
For example, if someone made a video driver, refused to release it open source because of contractual problems, but made it relatively easy to pick apart a bit at a time, it would give them plausable deniability, but still help out the OSS community.
~Will
Re:why do it by hand? (Score:2)
For example, if someone made a video driver, refused to release it open source because of contractual problems, but made it relatively easy to pick apart a bit at a time, it would give them plausable deniability, but still help out the OSS community.
You mean like not stripping the binary and leaving full debug info in there?
It happens, I can't say it's intentional but it happens.
Re:why do it by hand? (Score:2)
In either case, an OSS friendly company may be aware of the legal issues about rel
Re:why do it by hand? (Score:3, Interesting)
Re:why do it by hand? (Score:2)
Releasing driver source code that can be compiled is like giving a person directions to your house. Releasing a driver they're forced to reverse engineer is giving them directions through 20 questions. Yeah, they might get there...but they'll have to work MUCH harder, and it will take MUCH logner, and there's a chance it will never work as well.
Why not make the competition work as hard as possible? It's bet
Re:why do it by hand? (Score:2)
I could see the DMCA being a possible weapon against the competition but in most cases not the effort of actually reverse engineering a driver. If the competition is expert enough to be real competition anyway then the
Re:why do it by hand? (Score:2)
In reality, decompiling is a very difficult thing to do, and IDA pro (which they are using) does a very good job of this difficult task. You can be sure that by using this they are using one of the best tools available for dissassembly. It recognises functions etc but still retains all the low level ASM and optimised C code which is used a lot in the development of drivers which doesnt translat
Re:why do it by hand? (Score:2)
I've not used IDA Pro so I can't say how well it does but it sounded from his description if it stopped short of decompiling to C (or psuedo-C if you like).. and he did that step by hand. It just seem
Re:why do it by hand? (Score:3)
Not quite done yet (Score:5, Insightful)
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.
why hardware decoder? (Score:4, Insightful)
Re:why hardware decoder? (Score:2)
Re:why hardware decoder? (Score:2)
not to mention that many (most?) of them don't implement the SIMD instruction sets used to speed software decoding.
Re:why hardware decoder? (Score:2)
The secret? Stay away from Windows and MPlayer. And use a sufficiently accelerated ATI card with the open-source drivers. The XV extension makes a huge difference.
But other than that, you're right. Hardware MPEG decoding is dirt cheap (MPEG was designed to be decoded in dirt cheap hardware) and always nice to have.
Re:why hardware decoder? (Score:3, Informative)
Re:why hardware decoder? (Score:2)
After using MPlayer for a while, you know what your hardware can do, because you have to tell it all to MPlayer. It's painful, but educational.
Re:why hardware decoder? (Score:2)
The linux drivers don't do iDCT or motion compensation.
Former GATOS core team member.
Re:why hardware decoder? (Score:2)
ATI's Xilleon chipsets will do dual HD MPEG2 decoding, overlay, and display. They do have graphics overlay capabilities as well, but are primarlily designed for Set top boxes.
For the "official" word, search ATI's website for "Xilleon".
Re:why hardware decoder? (Score:2)
Mplayer plays dvds quite well (but then again I also know more about it) for me. I just wanted to know if there was a large reason (mplayer is not the most friendly to some sound hardware)
Re:why hardware decoder? (Score:3)
MPlayer is a really nice research platform for accelration techniques, but a media player it isn't. What killed it for me was its lack of support for DVD menus. Even if it did support them, it just didn't perform well, and I couldn't use it.
I've worked with the MPlayer source on several occasions, around version 0.50. It was an abomination - a monolithic design that couldn't be modified in any meaningful way without a rewr
Why a hardware decoder? - Because - It's a VIA (Score:5, Interesting)
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!
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:Why a hardware decoder? - Because - It's a VIA (Score:3)
Sorry, I do know someone who is contemplating building a very cheap (relatively cool and non-power hungry) cluster out of them. Which will (sadly) beat the SGI "High performance" system (either easily parallelizable, or single-threaded, non-super memory bandwidth (though they wouldn't do that bad on that either, considering the age of the SGI)) for a very small fraction of the price. (and it shoul
Re:Why a hardware decoder? - Because - It's a VIA (Score:2)
I imagine it won't be long before VIA 'fixes' this, but I'm not sure they're in a hurry to. The purpose of the EPIA mini-itx board isn't performance gaming. And to be honest, I'd hate to see them lose focus on what is working so well for them.
I suspect that no sooner than they add an AGP port we'll have Tom's, Sharkey's,
NOT reverse engineering (Score:5, Informative)
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?
Re: NOT reverse engineering (Score:4, Informative)
"In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work". United States Code, Title 17, section 102(b). [cornell.edu]
Re: NOT reverse engineering (Score:2)
Not all copying is copyright infringement (Score:2)
The author of the article did much more analysis than that, but even that were all he did, I think that would still be legal given the purposes for which he did it. Not all copying is copyright infringement.
"[...] the fair use of a copyrighted work, including such as by reproduction in copies or phonorecords or by any other means specified by that section, for purposes such as criticism, comment, news reporting, teaching
Re:Not all copying is copyright infringement (Score:2)
If t
Re: NOT reverse engineering (Score:2)
However, you ask a really good question that has been asked since the beginning of copyrighting software and the CONTU panel. Here is one reference [vt.edu] to it:
Can I have some of the crack you're smoking? (Score:2)
This is absolutely how reverse engineering works. And, in fact, this is almost exactly how I've been working the reverse engineering of Ten-Tec RX-320D receiver BIOS. I disassembled the source into ADSP-2101 assembly and have been meticulously putting together a pseudo-C version which is a lot easier to read and gives a much better representation o [sourceforge.net]
Re:Can I have some of the crack you're smoking? (Score:2)
As it stands it's straight copying, although since the license that ships with the code allows it it turns out he CAN do this, see other replies for details.
Re:NOT reverse engineering (Score:4, Insightful)
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.
Re:NOT reverse engineering (Score:2)
Re:NOT reverse engineering (Score:5, Informative)
* 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.
MOD PARENT UP (Score:2)
Re:NOT reverse engineering (Score:2)
Many a company... (Score:2)
Just like we like to champion choice in operating system and GUI, software companies have the right to choose their business and development models.
It is up to the OSS crowd to adapt to that, and what better way than innovation? It has already started with OGG.
Driver model broken (Score:2, Funny)
Ask and Ye Shall Receive? (Score:2, Insightful)
Has the article submitter actually asked them instead of going by a press release and venting on
Title should read ... (Score:2, Interesting)
Dxr3 (Score:4, Interesting)
reverse engineering? (Score:2, Funny)
is that what it's called now?
back in the day, i used to just double click on the mpeg clip on my computer, and all you could see were "reverse cowgirls". whatever these "engineers" (or pr0nstars as we used to call them) are doing is just great. My "intellectual property" is now as WIDE-OPEN as open source for you!
ackk kids.... when do they ever use the proper symmentics.. (old man like me cant spell...)
PVR era (Score:3, Insightful)
Look at it this way (Score:3, Interesting)
Is it a proprietary secret that "Esc", "K", followed by a two-byte binary number presented units-first between 1 and 480, followed by that many bytes, is the code used to select bit-image mode on an Epson-compatible Dot Matrix Printer? Of course not! why, Back In The Days, when if you wanted software you pretty much had to write your own, the printer would have been useless without such information. So the manufacturers used to provide it in the handbooks. Kit that didn't come with adequate documentation, didn't get bought.
Today, with pre-written software in abundance, manufacturers are becoming sloppy and not documenting fully how to interact with their products. For the casual user, this isn't a big problem, because they were never going to do anything with this information anyway, so why waste paper or plastic telling them it? But if there is even one user who wishes to do more than what it says on the box, then it suddenly becomes a very big deal indeed.
My analogy is that he used "reasonable force" to obtain information to which he was entitled, after polite request had failed. The law is quite clear that in certain situations, reasonable force may be used. This situation is more "gentle" and relies less on quick decisions than, say, physically moving a person who is trying to resist. {He could have obtained said information by holding a knife to someone's throat at the manufacturer; this would likely be seen as more than reasonable force.}
We should be writing to our elected representatives now to make sure it becomes mandatory for manufacturers to supply full hardware specifications, gratis or at cost, to anybody who wants them. Concealing details is a dirty, lowdown, scumbag, coward's trick that will cost companies sales. Please don't betray your cowardice by bleating about "competitors gaining an advantage" - you will have access to your competitors' documents, too, and if your competitors manage to do a better job than you, then you failed it! I have no sympathy, either, for those who whine that people might find it easier to break the law if they were given certain information. It is already more than easy enough to break the law. A few extra ways aren't going to make any difference here or there. You shouldn't rely on doing crap design and keeping things secret; it's another form of corner-cutting. Do it properly or not at all.
If the guy is ever taken to court, his best chance is to push for a trial by jury an hope that, out of twelve people, he can convince two of them that, although he does not deny what he did, it is the law that is wrong this time and they can acquit him. If this happens often enough the law will be changed.
Re:Software decoding works fine (Score:5, Informative)
-1, Wrong (Score:3, Insightful)
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 anal
Re:-1, Wrong (Score:2, Interesting)
There is only one reason to do this decoding in hardware:
SPEED
More accuracy in decoding a stream? In software you can take a variable that's as big as you want. Bigger variable => higher accuracy.
Additional features? Code 'em up, make a filter of 'em or whatever. Only takes a good concept and some time.
All these plusses you state as being the reason for using a hardware solution can actually be made using plain old software. The only reason they're n
Re:Why do you need source code to develop for it? (Score:3, Informative)
Re:The Wrong Thing To Do (Score:3, Interesting)
It's not like you'd need a Linux driver for it to be relatively straightforward to reverse engineer - most hardware drivers are relatively simple, they act as relatively thin layers to abstract out low level hardware access - and reverse engineering them isn't a big deal.
The most notable exceptions are winmodem drivers, where the drivers provide more or less a full modem protocol st