Is it legal to disassemble the proprietary VGA BIOS to learn how to enable a particular VGA chip? Of course, he (who?) will not copy any bits from the copyrighted code, he'll just pick up register addresses and values, and its order. If he would eventually write a code to enable VGA this way, can we share the resulting code?
-- Takeshi
On Tue, 2003-05-20 at 11:33, SONE Takeshi wrote:
Is it legal to disassemble the proprietary VGA BIOS to learn how to enable a particular VGA chip? Of course, he (who?) will not copy any bits from the copyrighted code, he'll just pick up register addresses and values, and its order. If he would eventually write a code to enable VGA this way, can we share the resulting code?
It is legal in France if the goal is to assure systems compatibility. Clearly, this case would be legal...
Amaury
-- Takeshi _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
On Tue, 20 May 2003, SONE Takeshi wrote:
Is it legal to disassemble the proprietary VGA BIOS to learn how to enable a particular VGA chip?
depends on what country you are in. I have no idea of the rules in Japan. We have avoided doing this type of thing in the US, because we have so many lawyers here looking for lawsuits to file. Even if it is legal we felt it was a bad idea.
ron
ron minnich wrote:
On Tue, 20 May 2003, SONE Takeshi wrote:
Is it legal to disassemble the proprietary VGA BIOS to learn how to enable a particular VGA chip?
depends on what country you are in. I have no idea of the rules in Japan. We have avoided doing this type of thing in the US, because we have so many lawyers here looking for lawsuits to file. Even if it is legal we felt it was a bad idea.
In America of course, anyone can sue anyone. But it is my understanding most lawyers agree reverse engineering is protected by the fair use doctrine of Title 17, limited by Chap. 12 which is the DMCA. In other words, if it is encrypted, you have to be careful. But I have never seen anyone claim object code was "encrypted". Anyway, I reverse engineer all the time. Highly recommend IDA from www.datarescue.com for disassembly.
(Note IANAL). The legal issue that came up in Sony vs. Connectix was the fact that in order to reverse engineer the Sony Playstation BIOS, Connectix had to copy the BIOS repeatedly to a variety of computers. The question was, was this unlawful copying of a copyrighted work. Ultimately the court found that the copying was "fair use" as long as it was "necessary" to create a non-infringing work. The functional aspects of source/object code are not protected by copyright (that is the patent law area), only the specific expression.
This is all American law, of course. And, one should note, that even though Connectix won, they went out of business due to legal expenses (as far as I recall). I think that is called being "dead right".
-Steve
On Tue, 2003-05-20 at 23:35, Steve Gehlbach wrote:
ron minnich wrote:
On Tue, 20 May 2003, SONE Takeshi wrote:
Is it legal to disassemble the proprietary VGA BIOS to learn how to enable a particular VGA chip?
depends on what country you are in. I have no idea of the rules in Japan. We have avoided doing this type of thing in the US, because we have so many lawyers here looking for lawsuits to file. Even if it is legal we felt it was a bad idea.
In America of course, anyone can sue anyone. But it is my understanding most lawyers agree reverse engineering is protected by the fair use doctrine of Title 17, limited by Chap. 12 which is the DMCA. In other words, if it is encrypted, you have to be careful. But I have never seen anyone claim object code was "encrypted". Anyway, I reverse engineer all the time. Highly recommend IDA from www.datarescue.com for disassembly.
If you are tracing the code with some kind of debugger rather than disassembly the binary image, does it matter if the image is encrypted ?
This is all American law, of course. And, one should note, that even though Connectix won, they went out of business due to legal expenses (as far as I recall). I think that is called being "dead right".
If Connetix won, why can it ask Sony for the legal expense ? With some additional "punishment" ?
On 21 May 2003, ollie lho wrote:
If you are tracing the code with some kind of debugger rather than disassembly the binary image, does it matter if the image is encrypted ?
Interesting question. You didn't subvert the encryption, the program decrypted itself! But in the US, i think this would be debatable and would probably boil down too how much you can spend on lawyers...
Speaking of such things, has anyone ever seen a license on VGA Roms? More specific than just a copyright i mean? I was considering how one could get past the problem of making commercial solutions when we don't know much about the video chipset. The solution in my mind is to sell the commercial appliance with the linux distro and the default commercial BIOS. On first boot up by the customer, the linux distro extracts the VGA ROM from memory and installs it along with linuxBIOS. Subsequent reboots then would use that VGA blob. This way, the company selling the appliance didn't copy the VGA ROM, it was done by the user. And I would think the user is alright under fair use? Is my logic faulty?
This is all American law, of course. And, one should note, that even though Connectix won, they went out of business due to legal expenses (as far as I recall). I think that is called being "dead right".
If Connetix won, why can it ask Sony for the legal expense ? With some additional "punishment" ?
Don't lose any sleep worrying about what happened to Connectix. http://www.connectix.com/about/acquisition_win.html
------------------ Adam Agnew Independent Contractor www.adamagnew.com
Adam Agnew wrote:
Speaking of such things, has anyone ever seen a license on VGA Roms? More specific than just a copyright i mean?
If you're buying the VGA controller the vendor gives the OEM a VGA BIOS along with the silicon. If you're an end user they generally don't want to spend any time supporting you.
--Bari
Adam Agnew wrote:
Don't lose any sleep worrying about what happened to Connectix. http://www.connectix.com/about/acquisition_win.html
Sounds like the reports of Connectix' demise were greatly exaggerated. I guess my info or memory was incorrect.
-Steve
ollie lho wrote:
If you are tracing the code with some kind of debugger rather than disassembly the binary image, does it matter if the image is encrypted ?
I guess it depends on why it is encrypted, and why you are tracing it. Encryption for copy protection, and access protection (ie movies and e-books), is covered by the DMCA. The language of the law is "circumvention", which basically means getting around the protection mechanism, and I don't think it matters how you do that, tracing, decrypting, whatever. There is an exception for reverse engineering for the purpose of developing interoperable software. For the case of a BIOS, one is developing interoperable software so it seems to be an exception, if the BIOS is encrypted (as in the Xbox).
But of course, IANAL.
-Steve
Hi!
If you are tracing the code with some kind of debugger rather than disassembly the binary image, does it matter if the image is encrypted ?
I guess it depends on why it is encrypted, and why you are tracing it. Encryption for copy protection, and access protection (ie movies and e-books), is covered by the DMCA.
While talking about the DMCA. If you violate the DMCA outside the US and this violation for whatever reason hurts the US interests, you can be prosecuted in the US whenever you enter US teritory. And it is a criminal offense too. So you might end up in jail when you are prosecuted.
Groetjes, Peter Busser
On Wed, 2003-05-21 at 13:48, Steve Gehlbach wrote:
ollie lho wrote:
If you are tracing the code with some kind of debugger rather than disassembly the binary image, does it matter if the image is encrypted ?
I guess it depends on why it is encrypted, and why you are tracing it. Encryption for copy protection, and access protection (ie movies and e-books), is covered by the DMCA. The language of the law is "circumvention", which basically means getting around the protection mechanism, and I don't think it matters how you do that, tracing, decrypting, whatever. There is an exception for reverse engineering for the purpose of developing interoperable software. For the case of a BIOS, one is developing interoperable software so it seems to be an exception, if the BIOS is encrypted (as in the Xbox).
Then why a DVD player with DeCSS not a "interoperatable" software ?
ollie lho wrote:
Then why a DVD player with DeCSS not a "interoperatable" software ?
Ah, yes, a very good question. This was answered by Judge Kaplan in the DeCSS decision (Universal City v. Reimerdes, US District Court, So. District of NY). The reason is that the US legislature (apparently) only intended the reverse engineering exception to apply to interoperating with _software_, not movies. So it only applies to software (at least in the Judge's opinion, which counts in NY and probably everywhere else until a higher court says differently). Which, among a whole bunch of other reasons, is why Eric Corley lost the case. The prosecution of Jon Johansen still goes on today AFAIK in Norway.
-Steve
Steve Gehlbach wrote:
ollie lho wrote:
Then why a DVD player with DeCSS not a "interoperatable" software ?
The reason is that the US legislature (apparently) only intended the reverse engineering exception to apply to interoperating with _software_, not movies.
I was working from memory here, and it has been pointed out to me that the final DeCSS decision does not state this. I don't recall where I read this, maybe it was an interim opinion, maybe I have it completely wrong. So to be very accurate, you should read the final DeCSS opinion yourself: http://news.findlaw.com/hdocs/docs/dvd/dvdopinion.pdf.
-Steve
Steve Gehlbach wrote:
Steve Gehlbach wrote:
ollie lho wrote:
Then why a DVD player with DeCSS not a "interoperatable" software ?
The reason is that the US legislature (apparently) only intended the reverse engineering exception to apply to interoperating with _software_, not movies.
I was working from memory here, and it has been pointed out to me that the final DeCSS decision does not state this. I don't recall where I read this, maybe it was an interim opinion, maybe I have it completely wrong. So to be very accurate, you should read the final DeCSS opinion yourself: http://news.findlaw.com/hdocs/docs/dvd/dvdopinion.pdf.
This has moved up to the Supreme Court. Lots of links are here: http://news.com.com/2100-1023-978985.html?tag=fd_top
-Bari
ron minnich rminnich@lanl.gov writes:
On Tue, 20 May 2003, SONE Takeshi wrote:
Is it legal to disassemble the proprietary VGA BIOS to learn how to enable a particular VGA chip?
depends on what country you are in. I have no idea of the rules in Japan. We have avoided doing this type of thing in the US, because we have so many lawyers here looking for lawsuits to file. Even if it is legal we felt it was a bad idea.
Also it is much more productive (in general) to just look at the registers and see how they get set. And extrapolate the meaning of the registers from there.
On the same scale you can usually capture the same information with some kind of ICE so you do not need to disassemble the code.
Eric
Hi!
Also it is much more productive (in general) to just look at the registers and see how they get set. And extrapolate the meaning of the registers from there.
On the same scale you can usually capture the same information with some kind of ICE so you do not need to disassemble the code.
An in-circuit emulator is expensive, right? Is it also possible to do this using something like Bochs?
Groetjes, Peter Busser
On Wed, 2003-05-21 at 15:09, Peter Busser wrote:
Hi!
Also it is much more productive (in general) to just look at the registers and see how they get set. And extrapolate the meaning of the registers from there.
On the same scale you can usually capture the same information with some kind of ICE so you do not need to disassemble the code.
An in-circuit emulator is expensive, right? Is it also possible to do this using something like Bochs?
If you are only interested in those IO ports, an logic analyzer is probably better and easier to use. Modern LA can be programmed to log/filter various IO scenario.
Hi!
If you are only interested in those IO ports, an logic analyzer is probably better and easier to use. Modern LA can be programmed to log/filter various IO scenario.
It's probably a bit expensive to buy an LA or ICE or any other specialised hardware just to get a board going. So I thought it might be possible to use Bochs to do the job instead. But maybe I'm mistaken.
Groetjes, Peter Busser
If you are only interested in those IO ports, an logic analyzer is probably better and easier to use. Modern LA can be programmed to log/filter various IO scenario.
It's probably a bit expensive to buy an LA or ICE or any other specialised hardware just to get a board going. So I thought it might be possible to use Bochs to do the job instead. But maybe I'm mistaken.
The problem with bochs is that it is not just "any hardware" but they attempt to emulate Intel 440LX (IIRC). So if you put here an standard bios I would expect it to complain a lot.
Of course it is still better than nothing and I believe there are people on the list which went this track before. Actualy it was other way around with getting LinuxBIOS bios to run under BOCHS IIRC.
While I myself hadn't used BOCHS to this purpose I have used Wine on regular basic, and I was able to *easily* track IO ports for communication between ChipWriter software and the ChipWriter hardware itself.
Just my two bits.
I have speculated that the XFree86 int10 code that (re)posts the card using I believe vm86 syscalls, would be a suitable test harness for this. So, boot off a second video card, then XFree86 will post the card in question in the DOS box when doing multihead or just running on the card that wasn't initialized at boot. If you were to modify the flags passed to vm86, not to allow IO, you just need a trap handler that logs the access then continues. For MMIO, page table permissions could also be used to generate traps, which log the access then continue, for the PCI IO region.
Jeremy ----- Original Message ----- From: "Adam Sulmicki" adam@cfar.umd.edu To: "Peter Busser" peter@trusteddebian.org Cc: Linuxbios@clustermatic.org Sent: Wednesday, May 21, 2003 9:07 AM Subject: Re: Reverse engineering
If you are only interested in those IO ports, an logic analyzer is probably better and easier to use. Modern LA can be programmed to log/filter various IO scenario.
It's probably a bit expensive to buy an LA or ICE or any other
specialised
hardware just to get a board going. So I thought it might be possible to
use
Bochs to do the job instead. But maybe I'm mistaken.
The problem with bochs is that it is not just "any hardware" but they attempt to emulate Intel 440LX (IIRC). So if you put here an standard bios I would expect it to complain a lot.
Of course it is still better than nothing and I believe there are people on the list which went this track before. Actualy it was other way around with getting LinuxBIOS bios to run under BOCHS IIRC.
While I myself hadn't used BOCHS to this purpose I have used Wine on regular basic, and I was able to *easily* track IO ports for communication between ChipWriter software and the ChipWriter hardware itself.
Just my two bits.
-- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
-
Adam Agnew -
Adam Sulmicki -
Amaury Jacquot -
Bari Ari -
ebiederman＠lnxi.com -
Jeremy Jackson -
ollie lho -
Peter Busser -
ron minnich -
SONE Takeshi -
Steve Gehlbach