| |||||||||||||
|
| |||||||||||||
Reverse engineeringReverse engineeringPosted Jul 20, 2006 9:34 UTC (Thu) by copsewood (subscriber, #199)In reply to: Reverse engineering by rwmj Parent article: OLS: Open source graphics drivers
"How feasible is it to run Windows and the Windows binary driver inside some sort of virtualised environment, and observe what PCI registers are written/read when various graphic operations are performed on the card?"
Can't comment on the technical feasibility of this (though with a suitable debugging environment this should be possible), but IMHO observing what something you buy does should be legal nearly everywhere.
"A free driver could then replay the appropriate sequences ..." I think doing this would classify as copying, and therefore would be a breach of copyright, so it wouldn't be a free driver unfortunately. My understanding of the cleanroom procedure to follow here is to for one engineer to study the observations taken from the debugger and to draw up a product specification, and another engineer creates the free product from this spec, not knowing the detailed implementation of it in the proprietary product. Replay would be copying at too low a level, but reverse engineering is legal in most places, though some local regulations vary, e.g. the DMCA prevents reverse engineering of certain products in the US.
(Log in to post comments)
Reverse engineering Posted Jul 20, 2006 19:16 UTC (Thu) by brouhaha (subscriber, #1698) [Link] "A free driver could then replay the appropriate sequences ..." I think doing this would classify as copyingNo, because the sequence of writes to the registers is not copyrighted, nor can it be under US law. The code is copyrighted, but the effect of the code is not. It is a purely functional aspect of the driver, not an expression protectable by copyright. (There is special provision for copyright of audio-visual works generated by software, e.g., the visual appearance of video games, or the "look and feel" of a spreadsheet program, but that doesn't apply in this case.) If examination of the operation of the driver (via a logic analyzer or a virtualization environment, but NOT by a disassembly of the code) reveals that it writes 0x12 to register 0x37, then writes 0x66 to register 0xab, it is perfectly acceptable to write a spec that says that to accomplish some particular operation, those two register writes should be performed. Then someone (possibly the same person) can write code that performs those writes. If the same information is determined by disassembly of code, then it is best to have a "Chinese wall", and have the person that disassembled the code only write the spec, and have someone else write new code based on the spec. the DMCA prevents reverse engineering of certain products in the USIt only prevents reverse-engineering of copyright protection systems. In the case of a video card driver on a PC, that only means that you couldn't reverse-engineer the way the driver controls the Macrovision feature on the TV out (if the card even has that feature).
Reverse engineering Posted Jul 21, 2006 6:08 UTC (Fri) by Ross (subscriber, #4065) [Link] Actually it doesn't mention reverse engineering, but it does affect it. You aren't allowed to bypass copy protection schemes even for the purpose of reverse engineering.
Reverse engineering Posted Jul 21, 2006 20:23 UTC (Fri) by giraffedata (subscriber, #1954) [Link] Some people recommend doing the two-engineer thing even where you reverse engineer by observing the effect of the program. Reason: Engineer #1 had a copy of the code in his possession, so someone might be able to (incorrectly) make a case that he copied it. Engineer #2 never had access to the code, so he's untouchable.
|
|
||||||||||||